One of the projects I'm working on is suffering from many of the ills that come with using Oracle on a project. At first we built the entire stack using PostgreSQL (like most sane projects should), but when it came time to deliver to the customer, they had not yet chosen to allow it as an approved software component and suggested we move to Oracle -- that was over a year ago.
We've fought every kind of licensing issue you can imagine, shitty support, broken tools. A simple migration of a few hundred rows in a very simple table turned into a month long exercise that required 200 billable hours to Oracle consultants because all of the import/export tools that Oracle provides are broken in subtle, different and incompatible ways. At one point we saved time by copying and pasting data from one table into another through the management GUI rather than fight all the bullshit Oracle puts in your way.
The customer, now irate that we've been in standstill for a year, doesn't understand and hasn't made any progress in getting Postgres signed off on by their security idiots and now they're out an extra million dollars or so.
From initial install to development to deployment it's been a nightmare and the only conclusion anybody can reasonable come up with is that it's because Oracle purposely breaks their software in subtle ways so that the only paths of execution require deep Oracle lore that only somebody who dedicates their job to being an Oracle DBA could possibly know.
Oracle can't die fast enough as a company. They're an enormous drag on the entire technology industry and I'm convinced a force for evil.
Companies these days chose Oracle for one reason. They're scared of being sued. Several operations I've been involved with chose it as insurance policy. They want the ability to defer litigation to Oracle should it occur. Oracle touts its support and aggressive legal defense as a selling point. Engineers don't recommend Oracle, C titles and Sr. Management do. Sorry to hear about your issues, I'm sure the product worked amazingly on Postgres.
It honestly never occurred to anybody to check. It's such a rock solid standard tool the notion that it wouldn't be approved and Oracle would be for some vague handwavy "security" policy reasons was not a notion that anybody entertained, not even the client PM, until we got to deployment.
Not to be a dick, but what kind of issues did you have with their import/export tools?
As someone who has worked with Oracle and Microsoft SQL databases for many years, you sound like someone who has never worked with their database. Oracle databases might be expensive but you can move data between instances and schemas using SQLLDR or DataPump with ease.
It's a fair question. Keeping in mind that we literally had nobody who'd ever used Oracle in their careers (or at least beyond fairly basic uses a decade ago)...we had a fairly simple set of tables, one of which had a CLOB attribute.
Every single export option available in Oracle SQL Developer truncated the CLOB field whenever it felt like, and half of the exported formats were exported without escaping content in the CLOB so that they were unparseable on import.
When we finally called in the Oracle consultants, they said "we never use the import/export tools in SQL Developer" and moved on to SQLLDR, but failed for exiting reasons last seen in 1980's computing like "Error in Index ORA-42321" and then other issues with the parser.
Data Pump didn't work for some reason only the consultants know, but "minor version mismatch" was something they liked to say.
I don't remember the final solution, but I believe it was a hackneyed combination of writing some python code to connect to one of the databases, dumping the table data to a bunch of INSERT statements then just copy-pasting the whole output back into SQL Developer and running it in chunks until everything could be inserted into the new table. We couldn't just write more python code to pump the data back in because of some permissions problem that nobody could ever quite resolve satisfactorily. We also couldn't just load the file through the SQL Developer because it would only load files that were sitting in a specific, inaccessible directory on that specific server, not through the GUI.
I think this was when the lightbulb went off in all of our heads and we collectively realized "it's this terrible on purpose"
Total shit show with hundreds of thousands of dollars flushed down the toilet for no additional capability, huge program delays and a good reminder why nobody uses Oracle for new starts on software these days, it's absolute garbage and a curse on any organization that sustains it.
Based on your reply, you had a bad consultant and you used the wrong tool to load the data. Dealing with CLOB/BLOB fields can be a hassle sometimes but that shouldn't kill a project. Both Datapump and SQL-loader could have both been options.
This brings me to one of my pet peeves, programmers tend to trash databases because most of them don't understand how they internally work. If you ask most corporate developers to generate an explain plan and tell you what is going on in the output, most couldn't generate the plan.
The real problem is that there's something like a dozen different ways to import/export data and all of them do something just a little bit different, even when their accessed via pretty much the same interface. Datapump didn't work because there was a minor version mismatch between two of the dBs, something like a single letter in the version. We weren't using any features at all that distinguished our use of one dB over the other, so the data should have migrated smoothly.
SQLLDR threw up a bunch of index and constraint errors that magically went away when we just copy pasted in the INSERT statements into the GUI tool. Why? Who knows, but we didn't want to spend another $400/hr figuring it out.
CLOBs shouldn't be some magical type that's impossible to serialize and deserialize. There's nothing particularly tricky about serialized text in almost any other technology context, except in magical Oracle-land where all the tools are broken and you can measure how many dollars each row of data is costing you.
We weren't doing anything particularly exotic, or sexy, just very very vanilla relational dB 101 stuff, and Oracle has managed to turn that into expert-level wizard secrets. It doesn't matter how Oracle internally works, if we have to know, especially for these kinds of simple use-cases. If you have to know, you may as well just write what you need yourself instead of relying on a tool.
I agree with stickfigure, defenses of this garbage end up becoming an indictment of it.
Sorry to break this to you but CLOBs and BLOBs are sort of a magical type field. They are a special kind of field that can hold up to something like a couple of gigs of characters or binary data in them. I'm not a PostgreSQL or MySQL admin but I would assume that you would have the same issues with those database pumping data in and out of CLOB/BLOB field type from database versions that don't match.
Based on what you were trying to do, maybe writing a simple program to read a record from schema A and insert it into schema B would have been easier and cost less.
> Based on what you were trying to do, maybe writing a simple program to read a record from schema A and insert it into schema B would have been easier and cost less.
Yup, that's basically the lesson learned. Oracle's tooling is terrible, it's just easier to write your own most of the time.
> Based on your reply, you had a bad consultant and you used the wrong tool to load the data
My experience is that the tools and the "experts" leave a lot to be desired.
I wanted to move schema and data from the customer's server to my server so I could troubleshoot and issue the users were having.
The customer had 3 full time Oracle DBAs and I contracted a few high priced consultants to help with this job.
It took 6 days to move it.
Oracle isn't hated because people don't understand how databases work, it is hated because it is difficult to work with. Things may be different now (we were using 10g) but it feels like the most basic tasks take days of work.
This has effectively allowed the consulting company and oracle to fleece the business and hold them at Randsom putting the company under tremendous risk.
We have been called in to untangle the mess.
To give you an idea millions have been spent to build an ecommerce portal with sales in the 1000's. The ROI will probably take years To be realized.
Some of the challenges dealing with the mess of a complete oracle stack:
- typical people who specialize in oracle solutions are just that. Specialist in the solution not developers.
- Unless you are using one of the more popular products. Finding information is practically impossible compare the google search for magneto vs oracle atg
- you cannot easily transition a competent developer to oracle tools due to the complexity
- some of the tools are complex for reasons I fail to understand simple things take a long time to achieve. Maybe hard things are easier but I have yet to see this
- they encourage bad practices, everything goes in the db including HTML templates the works.
I agree... it's a nightmare. Look at the Oracle Identity suite. It's a mess, crazy disjointed collection of SOA apps to spin up user accounts for god sakes.
Some friends are working on a project with these tools... they are a couple of years in and don't have password reset fully implemented yet, and cannot come up with a date for implementation.
With a commercial product like Microsoft ILM/FIM, a team of 3-4 people could meet 90% of project objectives in 90 days with 90% less spend. The other 10% would require some product evals or tool building.
How much longer do you all think Oracle will be around as a company? They burned all bridges with engineers long ago, and they're not going to be able to keep selling their blatant and expensive lock-in strategy to management.
Maybe when they finally do go under Google will be able to buy Java and MySQL...
I don't think you realize how the enterprise ecosystem works. There are legacy Cobol systems scattered all around the place. Corporations stick with their platforms for decades. This isn't the web development front where we change platform every couple of years. In corporations change is slow because there are significant sums of money invested in people and procedures. You just don't change that for the next flashy thing. And thus the future for Oracle is much more promising than it is for Google or Apple.
> the future for Oracle is much more promising that[sic] it is for Google or Apple.
That is a bold statement. Google has ~1/3 of the world who have access to the internet as regular users. Apple is a hardware maker with a very desirable array of products. I won't say I am a fan of Oracle, and I agree with you on how the lifecycle of enterprise adoption works, but that is a very far fetched conclusion.
First, large companies need to adapt quicker; while this has always been the case, the pace is accelerating. As pointed out above, Oracle has done some shit to alienate a lot of people, and have been for a while.
New companies grow up to be "enterprise". While they ard gouging and alienating their current customers and potential employees, people are NOT building on Oracle. They aren't being locked in.
As old companies (or their management) retire Oracle will have adoption rates like cobol. I am not saying tomorrow, nor this year, but Oracle is going to make big changes or see their MRR fade out with the salesy slicks who brought them on board 2 decades ago.
The internet is pretty fickle though. I still remember when people switched from Altavista to Google and from MySpace to Facebook. It didn't take all that long and look at those old companies now.
Whilst Oracle has done absolutely nothing the last few years other than crappy, me-too products they do have a LOT of luck on their side. Why ? Because nobody is touching the EDW (enterprise data warehouse) space. There are no new startups. No disruptors. Nothing. All of the excitement and growth is happening in the analytics space where companies are just sucking all the data from the EDW into Hadoop. And then doing feature extraction, modelling, machine learning etc there rather than doing it in the database.
So nobody is really going after Oracle/Teradata/SAP etc core business any more. It's just kind of forgotten arguably like Windows or Office.
You are confusing consumers facing products( Altavista, MySpace ) with corporate facing customers. The corporations have invested 10s of million or more developing products based on Oracle products. Changing from Oracle to PostgresSQL is possibly many years of work and multiple projects for a large company.
I agree the companies are unlikely to rework the current code from Oracle to PostgreSQL (or some other database), but they'll definitely think twice when starting new stuff.
When managers start a new project, they don't want to think twice. They want to grab the ass of someone else in the company who's already done the same thing and leverage their expertise to reduce the cost of the project.
My company is still stuck using CVS because when a new project starts up, they want to use the people who are already locked into the old tech and so they end up going with what people already know. Even teams that started with git have downgraded to CVS once the managers starting looking for ways reuse resources.
It's always a cost/benefit evaluation. When the costs stay roughly constant, the outcome is usually to use the same stuff as for previous projects. But when the vendor significantly increases the costs, like Oracle does in the recent past, that may have significant impact. It may be easier/cheaper to switch to a different database, for example.
I'm not saying all companies will end up doing that, but some certainly will (and already do). They may not be vocal about it, though, because they don't want to piss Oracle.
> Changing from Oracle to PostgresSQL is possibly many years of work and multiple projects for a large company
Enterprise IT is broken enough that those multiple system replacement projects were going to happen anyway because of accumulated technical debt and broken development and maintenance processes, and replacing a backend DB as part of that replacement is a rounding error in expense. Sure, it takes a lot of time for the transition to be complete, but lots of those transitions off Oracle are already underway.
Speaking as an enterprise CRUD developer wage-slave, if you need a PhD from MIT to figure out how to migrate from Oracle to a sane database like Postgres or SQL Server, you probably should work in a different field or at least a different project.
More realistically, it's department politics that are going to prevent any sort of migration.
"The internet is pretty fickle though. I still remember when people switched from Altavista to Google and from MySpace to Facebook. It didn't take all that long and look at those old companies now."
Past performance is no guarantee for the future. We zillions of PC manufacturers before we got the likes of HP and Dell, and twenty years later, we still have them. On the desktop OS/application front, the same happened with Microsoft becoming the main player.
The common theme, I think, is that things are chaotic while there is room for everyone to grow, but get more predictable once the entire pie has been divided (aside: that's an argument in favor of Uber's "land grab at any cost" strategy)
Oracle, Google, or Facebook may eventually disappear, but it won't happen at he time scale at which Altavista or MySpace did.
At a prior employer, the CIO was so pissed off about Oracle licensing that he seriously considered freezing Oracle versions (as a prelude to migration off the platform) and buying third party support from Rimini Street.
If enough businesses pursue that option, then the cash cow of annual support dries up and Oracle is in a world of hurt.
"If enough businesses pursue that option, then the cash cow of annual support dries up and Oracle is in a world of hurt."
They could just raise licensing costs. They've already won on API copyrights. Businesses would have to move everything off Oracle entirely with new API's to avoid legal risk. Such moves, esp if Oracle docs suck as much as claimed here, can cost a fortune with huge chance of breaking stuff. Oracle just has to keep cost of licensing lower than that of a move.
They also found a new way to apply that same model with 0365 and their continual effort to add new features that only cost a "few dollars more per user per month"
Squeezing locked in customers is the Enterprise Software way... all of them do it.
>Squeezing locked in customers is the Enterprise Software way
No doubt about that, but for basic infrastructure like DBMSs the customer of the future will be another tech company. Try extracting the same margins for a database system from, say, Airbnb or Uber as from a mid-sized bank founded in 1888.
I don't disagree in general, but Oracle is a tech company and technology has a particular function in our society that wasn't invented by MBAs.
The role of technology is to drive productivity growth, which is ultimately the only thing that improves living standards (or at least has the potential to do so).
A pizza sold in 1987 is just as useful as a pizza sold in 2017 measured by its nutritional value. But the same is not true of technologies from 1987.
Oracle's lockin doesn't just come from their database. There are also behemoth business/logistics/financial applications that exist only as PL/SQL packages and a bit of Java UI. Moving off Oracle Applications is a lot harder than switching databases.
Even at their most dominant, Microsoft kept adding things customers wanted. AD was a big leap forward for customers, when Microsoft could have rested on the domain model. SQL Server kept adding capabilities, Exchange, etc.
All designed around Vendor Lockin, then putting the screws to business with various and complex licensing
CAL's for example would never be possible with out Vendor Lockin, What kind of extortion scheme do you have to have to sell a server licence then charge for every thing that wants to connect to the server.....
CALs - you mean like literally every successful SaaS solution on the market today? CALs are alive and well and aren't EVER going to die. Salesforce.com? CAL. Openair? CAL. Workday? CAL.
I don't think that says a whole lot about Oracle's growth opportunities as everyone moves to the cloud.
Direct licensing costs are not all that matters. The restrictions on architectural choices and the uncertainty created by these complex licensing structures could hurt them a lot more.
You are totally correct about how change is slow in enterprise, and this favors Oracle tremendously.
But I don't think you realize the extent of Google's ubiquitousness. Innovation is a survival strategy, and between the companies you mentioned, Oracle comes last in that front.
Google's lack of a rich enterprise cultural workforce consisting of account managers paired with a culture of sales and services for profits makes a great deal of enterprises nervous since this is how they're structured for business for several decades. This is where Google's partners that are more versed in such traditional, engineer-hostile come in, but then you wind up where massive companies start to rely upon maybe 1000-person companies that will be crushed by the onslaught of horrifically mundane, non-scalable problems endemic to a customerbase consisting of non-technical people and sub-par engineering talent as standard. These companies know that they can't use these smaller companies and are not run by stupid people (usually), so they have really little choice among technology vendors that make most of the HN crowd cringe.
So Oracle's future is based on those large enterprises, while the more nimble, those that will be large enterprises down the road, steer away from Oracle? Maybe Oracle realised that they won't be winning the smaller one's over and now decided to squeeze the larger ones even more.
Nope. Once you're big enough to start worrying about public company financial processes, your new CFO is going to buy Oracle Financials.
This particular price change is all about customers moving away from old RISC systems and IBM and towards x86. Amazon dramatically overprices Intel cores, so Oracle wants to capture that value. Cheap licensing for x86 is subsidy for AWS and Azure. They are spiking the pricing to push you into Oracle/Sun hardware or the Oracle cloud offerings. "Hardware and Software Engineered together" isn't limited to technology engineering!
Or they realize that your small nimble companies will "grow up" and hire experienced managers who will put in place rules that require mature vendors and Oracle gets another generation of company. Happens a lot, sadly. Idealism gets beaten and the people who don't like Oracle jump ship to new and exciting nimble companies.
DB2 is a bit of a different kettle of fish for a few reasons:
* DB2 rolls new features in at their top pricing tier, then trickles them down. So things you could only get in the top tier in 9.5 (for example) are now available in Workgroup edition in 11. Oracle keeps very old features (e.g. partitioning and encryption) as expensive add-ons.
* DB2 is still pushing out new features. PureScale has (for example) moved from parity with RAC (clustering in one datacentre) to well beyond it (metro clusting across a region).
* DB2 respects pretty much any VM technology for sub-capacity licensing. Oracle pretty much require you buy OVM.
Top-tier DB2 and a fully loaded Oracle DB are pretty similar pricing (depending on the specific deals you can obtain from your account manager), but DB2 keeps moving, and many of the features you might care about can be had in much cheaper editions.
The problems DB2 face are mindshare (easier to find DBAs for Oracle, many people still think of DB2 as a "mainframe thing"), and there's still quite a few "enterprise" apps that only support Oracle DBs.
Don't forget the risk of an expensive screw-up when switching to a new system. Unless there are clear business advantages, switching to a new system from an old, archaic but battle-tested system doesn't look enticing for most companies.
> And thus the future for Oracle is much more promising than it is for Google or Apple.
I'm not sure that's true; it's may be true that Oracle has more Enterprise penetration now, but enterprises with significant Oracle dependencies I've encountered are mostly migrating out (largely to Microsoft) -- including enterprises that also have substantial decades-old COBOL mainframe legacy that they aren't as actively working to retire.
Oracle will be around for many, many decades to come. Especially since in the enterprise world nobody could care less what engineers thought. Managers determine budgets and capabilities. Architects determine what to purchase and how it fits together. Engineers implement. Pecking order that's been around as long as Oracle has.
The biggest obstacle to Oracle's future success isn't price or other databases. It's the analytics space i.e. Hadoop/Spark which is relegating big iron SQL databases to being dumb CRUD boxes. It's why both Oracle and Teradata moved into the space but have struggled to get any traction against Hortonworks or Cloudera.
Oracle actually has a product called Big Data Appliance (and has been for a couple of years IIRC), that offers Cloudera-based clusters. They also offer that as a cloud service so you don't have to actually own the hardware.
Not sure how much traction is having vs Horton or Cloudera, but I'm sure a lot of companies that already buy Oracle would look into it if needed.
But those engineers retire, new ones without memory of Oracle's past take their place, and all will be forgotten.
Remember how Microsoft was the company many engineers hated when the Halloween Documents [1] came out? Yet, they have managed to patch up that relationship since 1998.
Yeah, my new boss laughed when we complained about Oracle. He adamantly insists it was the best database in the world. He also knows only one database.
It is a fantastic database. Best is a subjective term but for a MVCC translational workload it's amazing. Note that I'm talking specifically about the database itself, not the cluster fuck of end user software built atop it (ex: Oracle Financials).
The phrase "tune it via their CBO" doesn't make sense.
Oracle DBA here who hates their licensing, practices, etc. as much as the next guy, but I have to hand it to their query optimization. I've seen their optimizer get better with every major release, and yes, regression testing will always turn up a few problems but Oracle gives you the best tools to analyze and override the decisions that the optimizer is making when necessary (and I'm not just talking about basic hints here)
If you changed the case of a table name, this means you had to change whatever was generating the SQL since mixed or lower case requires table or column names to be surrounded by double quotes.
So, you changed code and didn't test it. Yup, definitely Oracle's fault.
Except that's not what I'm referring to. As with any cost based optimiser, it's only as good as the statistics it has to work with, and if you've finally carefully tuned your database with an appropriate histogram on a critical table, and found that after an upgrade they "tweaked" the CBO to fix a statistics calculation then you are right back to looking at explain plans to fix your performance issue.
Sometimes you just aren't going to pick up this sort of thing in testing as you'll only know about it under full production load. Their CBO is pretty powerful, but by and large it's often difficult to know why it makes certain decisions. And that's even when you use their full suite of profiling tools!
In all fairness, I can't really blame Oracle on this one. That's a fairly well documented issue, because Oracle places the hash value of each query into the shared SQL pool, and if CURSOR_SHARING is set to exact and you've stopped the query from aging out then Oracle will see it as a different query.
That's not even really a CBO issue. But I hear your pain :-)
> Oracle sells to managers and executives and are very, very good at it
I agree, but the point is that they are getting worse. Their cloud shift is not panning out as well as they wanted, I think, and they are actually opening opportunities for competitors: if you have to make significant efforts to migrate your existing solutions, you might as well move somewhere nicer. And by basically threatening their own partner ecosystems (which won't be needed in the new oracle-cloud era), they're losing steam in sales and presales.
(Of course, it doesn't help that Safe Harbor first and Privacy Shield now have been shot down, so European businesses are not keen on moving to US-based clouds. The sort of businesses Oracle pines for, does care about these things.)
Isn't gross income a bit misleading if they need to buy out larger and larger companies and harvest their products/good-will with an increasing portion of that gross income?
I've had two jobs in the past that have been in Oracle shops and from my experience those companies were so fully invested in a lot of the Oracle suite (think WebLogic, ESB, the database etc) it would be like turning a huge oil tanker around to pivot away from it.
And don't forget the reams of PL/SQL that often sits at the core of a lot of business logic
Eh, that's true just about everywhere... Code = Money.
You spend some money, get new and hopefully better code, and with some luck you will get a return on the investment, ie more money than you spent on doing it.
Unless you are doing it for fun. Or don't know what to do with all the money you have.
I laugh at how the only thing discussed here is open source software and the cloud. People forget that there's a whole entire world of enterprise software and systems.
As someone else mentioned earlier, mid to large size companies don't replace systems like people do here with Javascript frameworks. It is really expensive and costly to replace systems that have been around for decades. The business logic tied up in some of these systems is so vast and complex that it is cheaper to keep them around than to replace them with something new.
I would restate it that there is deep business logic encoded solely in a system that grew organically over decades. It's not always that it would be hard to rewrite it all... It's that no one knows or has documented anywhere except this organic code base all of the requirements. And specifically no one has encoded WHY.
So rewriting and keeping the same logic is very difficult and the business risk is very high due to all the unknowns: features, time, compliance, correctness, performance.
I agree with the sentiment, but they do make fantastic acquisitions though. of course Sun with Java, MySQL, and VirtualBox, also Dyn, Ravello, Addthis, Crosswire just to name a few
Since reputation of Google here is it shuts down projects/products. Do you mean Google buy Java/MySQL and shut them down? I do not see any other reason to buy either of those considering they can and are using Java and MySQL as and when they need.
Oracle has a huge client base in the gov't and healthcare sectors (at least in the US). Gov't and healthcare also lean heavily on solutions vendors who tend to use Oracle. This is a sector that is easily 10 or 20 years behind the curve in most places, so Oracle offering their me-too product line-up is safe and reassuring.
I think that a key explanation of Oracle success is that the complexity of their database administration has created a generation of full time jobs: DBA. These people are like salesman working for Oracle to defend the future of their job. They are well paid, but this cost nothing to Oracle. At the opposite, Oracle can sell training.
Most of these jobs are offshored now, so it's not as relevant a factor as you think. What is relevant is the amount of business applications and solutions built on the database, that took years to develop and would cost a fortune to replace.
DBA jobs haven't been entirely offshore'd. It happens in cycles.
* Offshore to save money. Databases are a car, just follow the script / maintenance manual and everything will be okay right?
* Discover the awful quality, security, never-ending cycle of bodies, lack of retention of information, zero innovation, frustrated staff having to try to deal with them, and and most of all costs which creep up (a lot like Oracle licensing).
* Insource to qualified internal staff and retain knowledge, save money, and fix all the problems the outsourced company wouldn't.
* Now that everything is fixed, create work manuals, and offshore again. This will get out of date over time, servers will get replaced, new software comes along, and things go to pot again. Repeat.
To be fair, companies also often institute long and complex policies which stifle any kind of remediation an offshore staffer would do - because they can't. Internal employees learn the system, how to get things done, and they do it.
I work for a team that has taken over from multiple offshore companies in this way. We find all of these things and worse, really just the most awfully maintained systems around - no backups, no maintenance, no organisation, nothing. They don't even patch but they say they do! And they've paid millions (and tens of millions) for the privilege!
There's really no comparison so don't mistake the two for a second. As for automation - well - tools have made it so that one DBA can "manage" hundreds of servers at once if they're standardised in certain ways. But you'd be surprised at how many things can go wrong and how few can be automated, especially when the rest of the companies don't have proper automation infrastructure in place. Large enterprises are still fiefdoms of managers who want local employees and to retain their own jobs.
Performance tuning and improvements though are extremely time consuming. You can, for some projects, focus entirely on single digit servers for years at a time if they're important enough.
For certain values of "support". Say you start on Oracle and then want to move to SqlServer? Migration will likely be a risky endeavor, even if the application supports either db when starting from scratch. To begin with, you'll need something to copy schemas across, be it in the app itself or not, and hope everything made it across. Then you'll have to hope the app doesn't need db-specific stuff (say, a sequence that you only get on sqlserver) that you don't have because you started on Ora. And then you'll have to move all the 3rd party tooling and hacks that you built over the years around that same database - from backup solutions to custom queries etc. It's rarely as easy as "copy it all and turn it back on", and all this work often has to be done by expensive application specialists.
At that point, having to choose between paying hundreds of thousands to move db, or a few extra thousands per year to keep things as they are, the business decision is not as simple as one would think.
Oracle DBA here. Oracle Database 10g through 12c have provided me with a steady income for 6+ years, but enough is enough. It's a solid, powerful product, but Oracle's behavior over the years has been so ridiculous, so abusive, so damaging to open source. . . I've had enough.
Am doing exactly what you suggest. All of my personal projects now run Postgres.
The Exa* pitch complicates that, though. I've dealt with Oracle DBAs who were rabid to get their hands on Exa* units so they could "get rid of the sysadmins." They cooled their jets when they heard a big part of the Exa* pitch is reducing reliance on DBAs, as well.
Oracle's in an awkward place. They want to get to the new world of cloud and appliance without burning down the old world, while preserving their profitability, and that's quite hard.
I'm not expert in licensing too. I've friends who said, when they needed enterprise support for Oracle DB running on Redhat, directly/indirectly the message they received is to migrate from Redhat linux to Oracle linux. I think that quite clear by some kind of 'cold-war' going on between Redhat & Oracle.
Oracle is worth every penny that they charge. Unless you've worked with it, you won't understand the love / hate relationship toward it.
Yes. It costs money. Why? Because it does so many things that nothing else comes close to. Its query optimizer is insane. MySQL is a toy and PostgreSQL, while admirable, remains in a lower class.
I say this as a supporter and contributor to open source databases. Like the open source cars of tomorrow; you can't compare them to the pedigree of a Porsche.
I was always a Sybase and DB/2 guy myself, but Oracle could do things. Things Sybase couldn't be tuned for. You don't put Wordpress on Oracle. You do crazy insane shit on it that will break MySQL.
I think you are not taking into account the shift out of the DB and into the application layer. People care less and less what the DB can do. Yes large slow enterprises will continue to have a need for Oracle DB. But I've never seen anyone connect a microservice to Oracle. Why? Because you dont need that much complexity when you only have a collection of "simple" services.
That shift is somewhat insane though. Moving data out from the DB just to do stuff in the app that could be done inside the database is throwing performance out of the window.
In my experience using Oracle is throwing performance out the window. It's not uncommon to have 40+ machines running an Oracle product that struggles to support 1-2k concurrent users. For instance the Oracle Identity Manager, which is glorified LDAP was deployed on about that number of boxes at a previous company I worked at. It took over a year to implement and they still only used the LDAP functionality. In the end it was falling over under load testing of just 10k sythetic users. It needed to support 100k.
I built up a single OpenLDAP box, just using the standard mdb backend and a ton of RAM. Easily crushed the load test.
Sadly could't be implemented for political reasons.
Screw Oracle, especially if you care about performance.
I don't know about the Oracle identity suite but I'd like to say that OpenLDAP is a ridiculous joke. (Just like the MySQL/PostgreSQL vs Oracle DB debate at times).
The only scalable LDAP server is the one from Sun Microsystem (openDS). It was killed when Oracle acquired Sun because they already had identity products. Then the sun guys quit to continue the products line under their own company, ForgeRock. https://forgerock.org/opendj/
I've done load testing and this ldap is taking millions of accounts, no problem.
The best products are rarely free once you get out of the average web dev context. Funny thing, this one is both paid and open source.
OpenLDAP can also handle millions of accounts, is open-source, supports awesome replication and availability topologies and doesn't require any consultants or otherwise bullshit dependencies/support contracts.
I'm sorry but there isn't a commercial product that can compete with OpenLDAP and there may never be because it is just that good if you know how to use it. (yes, the learning curve is high, that is the only criticism I really have of OpenLDAP).
Here's a little known fact for you: OpenLDAP is a commercial software made by a company called symas. https://symas.com/
The open-source edition is only a facade with highly stripped features.
If you want any decent replication, HA, performances or bugfix. You have to pay for their OpenLDAP gold edition, which last I checked was $100k for a site license.
Depends on your definition of highly stripped, decent replication, performance or bugfixes.
If you don't pay Symas money then no, you won't get support, or bugfixes developed for you.
However I doubt there is a large performance difference, it's already very efficient so it would be in the single percentage points.
As for replication you can do almost anything with the open-source version by combining syncrepl/delta-syncrepl into the topology you want, hell you can do N-way multi-master if you wanted.
I'm not sure what you have against using open-source OpenLDAP, maybe you should try it first?
Oracle's IM suite provides some questionable value. It's passable technically, questionable from the biz perspective and in reality is a land-and-expand product with lots of optional modules that Oracle is happy to 'advise' you about.
Technically it works... sometimes. Custom shims have a tendency to lead to complications because the API isn't very well-exposed or documented... it was another acquisition product.
Infrastructurally it's an unmitigated garbage fire. Oracle seems to think, e.g., your organization is too stupid (which is true, since you're an Oracle client) to know how to connect to AD from a nix machine or Java application, so the hardware footprint is huge.
It's questionable biz-wise for two reasons. First, because it's sold as a "complete", off-the-shelf solution when in reality it's probably about a dozen analysts working on it full-time for months just to get its biz logic set up, and then a handful for maintenance. Second, because OIM aims to be a institution-wide, one-stop-shop product (which it is* good at), but institutions that acquire it are so large that they're bereft with inter-department politics and policies that make using it firm-wide difficult.
You are so right. The next generation of a big app at our place using Oracle fusion middleware is ~10 times slower than before. They have converted simple function calls into web service calls.
> But I've never seen anyone connect a microservice to Oracle.
As a matter of fact, I did so multiple times in order to provide simple JSON APIs which consume data from massively huge enterprise software and expose them to nice shiny web apps. Can't name any more details though, but it works - at least if you use PHP, but I believe there's also an Oracle DB driver for nodejs, and most certainly for Java/JDBC.
No application, especially enterprise applications can have all business logic in the DB. It is spread out over huge, _multiple_ application code bases & even shell scripts and ad-hoc jobs.
So it doesn't matter how "good" the DB is. If the App & presentation layers are so bad, that they introduce logical or other anomalies every so often, does it matter if the DB does not produce any error in a billion years?
The Porsche analogy is cute. But if the business case could be solved by 10 scooters, isn't it be better & cheaper? When your "Porsche" is down, all customers are affected. With 5 scooters down, only 50% can be (if you design it that way).
In many of these so called "enterprise" applications, what they _needed_ was 10-20 scooters, but they bought 2-3 Porsches. And it's usually because "no one gets fired for buying IBM". In many internal apps, companies literally are putting Wordpress like shitty CRUD CMS on Oracle because of this mentality.
OK, so the one point you've brought up is the query optimizer... do you have any data to back this up? a comparison between query speeds for trivial & non-trivial data sets/queries?
Could you put into words a little bit more of what the Oracle DB does that Maria/MySQL/Postgres could not?
I think the Oracle license prohibits people from publishing performance benchmarks of Oracle against other databases. Or at least that's what I remember.
Welp, that's dissapointing, but it gives me a solid reason to never ever trust the claim that Oracle is "just better" than anything else. Claims without proof should hold very little weight with any critical mind. I'm totally open to the idea that Oracle is better in at least some ways (surely their engineers aren't just twiddling their thumbs all day), but I need to see it proven.
So far the features that oracle had that people have mentioned:
- An amazing query optimizer
- Replication (enabling High Availability) features available 15 years ago
- Oracle was the only SQL DB able to shard. (might still be)
- Oracle was the only database able to take multi GB or TB of data in a single table/DB. (Old MySQL/Postgre had various limitations like X GB per table for a long time, they still do).
If you worked in the DB in the 200X years, Oracle was the standard and for good reasons. MySQL/Postgre were considered like toys, for good reasons.
Example: Oracle could do live replication and HA 15 years ago. Postgres introduced it recently -- if my billion-dollar company was relying on a single logical database, I'd sure as hell wait a few years to see Postgres HA stabilizing before considering using it.
So replication & high availability -- I assume these two points are one (as replication features would enable high availability).
I understand what you're saying to mean simply replication, NOT a proper distributed database system allowing/facilitating writes using what we now know to be state-of-the-art theorems/methods. To rephrase, I assume you mean oracle dbs let people write to one database, and send updates to some mirrors somewhere else.
Just google it for yourself. This is a forum, not every post needs to be a peer-reviewed scientific paper. If you don't believe the OP then go ahead, but getting him/her to jump through hoops to try to prove a point is dumb.
In this case, there is literally no data to back up the assertion because Oracle don't allow it.
However, as the creator of [citation needed], I'd just like to say: if you want to say something in a forum, and it seems wrong, then I for one welcome data that backs up the assertion. Why should we take any one on face value?
While I understand your point, I think that where HN falls on this spectrum is precisely why HN is valuable (and what keeps it from becoming just another reddit clone).
You're absolutely right in that the OP has no obligation to 'jump through hoops' to prove their point (and again they are free to not reply), but people on HN generally don't make claims without at least some citation/proof, and that's why (to me, and I'm sure others) HN is valuable. Everyone has opinions. The expectation on HN is usually of reasoned discourse, and fact-driven analysis (where applicable)... While this is a minor inconvenience for posters/community members, it does a whole lot to solidify HN as a worthwhile place for people who care about that kind of thing to hang out.
> I was always a Sybase and DB/2 guy myself, but Oracle could do things. Things Sybase couldn't be tuned for. You don't put Wordpress on Oracle. You do crazy insane shit on it that will break MySQL.
I'd highly doubt that there's something one can do with Oracle that couldn't be done with a FOSS database - although it's certainly true that it requires more servers but servers are a commodity these days anyway.
What's going to keep Oracle in the market is the amount of enterprise software that has been written without database abstraction and would require complete rewrites to support anything else than Oracle as its engine.
The only exception to that I know of is SAP which supports MySQL backends, but then again SAP is only used by companies big enough to just mindlessly shell out big bucks for Oracle too if that's what they already use.
While I mostly agree with the general point you're making, please do not confuse one particular kind of heavy work with the much more general "real serious use".
Random case in point NASA is using pgsql for handling data streams from several of their probes, is that not real serious use ?
Years ago Oracle would have been in a quite nice position to put up interesting cloud offering. Something like Java platform as a service, bundled with the message queues, database etc. Not targeted just to enterprises, but similar to AWS and Azure in the sense that you can get started small. They had quite much interesting related technology from Sun and BEA (and of course from themselves).
And maybe this would still make sense. Java is still relevant. JavaEE provides the packaging for the applications. Maybe the basis for a nice serverless offering (you have for example the message driven beans).
5 years back it would be very interesting proposition. But today a lot of modern cloud infrastructure is getting written in Go. IBM/SAP/Apple betting on Swift for server side applications. So in past it could have been Swift app + Java backend now it is more likely Swift app + Swift backend.
I also think with Rust taken up by programing enthusiasts which otherwise would have prefered Scala on JVM is also going to put pressure on Java/JVM.
Yes, enterprise apps are not yet there. But lot of infra-like software would have been written in Java if Go were not there. There is growing awareness of Go at big enterprises such as where I work.
It will start with sucking oxygen for new projects which would be by default in Java.
The thing you need to understand about Oracle is that it's never — well, never in my experience, and I've worked as a DBA (mostly postgres, but I have had my hands on some Oracle) for a decade now — chosen by the technologists. It's chosen by management. Usually non-technical management. Often dangerously so.
But Oracle support basically doesn't answer the phone unless you're regularly cutting them six-figure checks, so you kinda need that level of management to be making the decision whether or not to use the platform.
In an Enterprise, you almost never buy 'a database'. There's a solution/application that you buy, that will have a supported DB backed (usually Oracle or MSSQL). That solution is mostly picked on business capabilities and functionality. The technical component is only one aspect of the requirements, which cover business capabilities/features, technical fit within existing environment, data migration/compatibility, vendor support, vendor credentials, the amount of training required, the amount of business change needed, etc.
These projects often cost $10m+, once you factor in the technical implementation and integration, business process changes, training for business staff, training for IT staff, transition costs, etc.
So if you want to argue that the business should get the solution that fits their requirements the second best, because the 'best' one has an Oracle backend, you had better come up with a shit-hot reason that can't be solved with 'hire a couple of Oracle engineers'.
"That solution is mostly picked on business capabilities and functionality."
Exactly - cost of support/hosting/licensing the relevant database is a factor but, in my experience, it is a pretty small part of a large ERP or CRM implementation.
That's cute. And it might even work in a startup. But likely not.
But in the enterprise world nobody really cares what engineers think. You have Enterprise Architects, Technical Architects, Solution Architects etc. who get paid exorbitant amounts of money, are political animals and can masterfully straddle the line between business and technology. Most of them are ex-engineers so they aren't entirely useless and since they have their own language they will make you look stupid. Can't articulate the transition from a tactical to strategic solution and explain what business capabilities it aligns to ? Well good luck getting that past the central Enterprise Architects who will need to sign off on your choice before it heads to Procurement/Legal.
Architects along with IT managers and CIOs are the people whom the famous Oracle Sales machine targets with golf games, overseas trips and fancy dinners. It's never engineers. I spent a few years at Oracle. They are a multi billion dollar company for a reason.
I can confirm this. Oracle goes out of their way to make senior and upper-mid management feel like rockstars. All expenses paid meetings in attractive overseas destinations, start to finish hand holding on multi-million dollar engagements, regular contact and personal attention. Management swoon and sign the cheques. And why wouldn't they? After all, it's only the company's money, not theirs personally.
Why? This is basically how the business world operates. There is nothing wrong with a private business wining and dining a potential client to swoon and sell them something.
You will be investigating likes of Microsoft, IBM, and even Amazon.
As an example, I can't stop the CIO and board at my company from talking about the cloud because of all the consultants and sales guys talking to the C suite. You want to see something really oversold right now look no further than the cloud.
'Wining and dining' is very common, but it's not necessarily considered 'corruption' because a meal is well, just a meal, after all. The occasional tickets etc. are just a 'gift' not ostensibly supposed to interfere with the purchasing decision.
Of course they do on some level.
But it's a fine line.
It's crazy how many CEO's will let purchasing decision makers be taken on these things and junkets, I would just not allow it.
But also don't doubt the ability of people to just drink koolaid. There are tons of non-thinkers out there who just 'buy' the story presented to them.
Also - I don't think 'the cloud' is oversold. It's definitely the future, and it's going to be the 'new normal' and it's here to stay.
The notion that anyone would 'host their own' stuff just doesn't make sense anymore - unless there are specific reasons for it. 'The cloud' is now the 'default choice' for most things, unless you have a need not to use it.
I never said the "wining and dining" was illegal or corrupt. I just think it is a easy way to get decision makers to push the people under them to look at technologies that may or may not apply.
In the case of the cloud, I agree that there's a future for it. But I think in the future people are going to look around and notice that it cost a lot of money to run everything in the cloud and on-premise is going to start looking good again.
Yes, those issues are important, and I was aware of them
For a start, that's why I don't work (at least directly) for the enterprise world.
But I've seen companies adopt open source solutions and modernize. I've also seen companies use those "legacy" technologies. They're the ones that usually go bankrupt, unless technology is a minor part of their business.
And yes, as much as "corporate architecture" is 90% BS and politics, if you can at least explain why solution A is better than solution B in a way it's understood, then you did your part.
And the question remains, who will pick up the phone when an open source DB fails to perform as it should. Does Red Hat provide support in that area?
Support is the biggest issue with open source. It's why companies like RedHat, DataStax, Hortonworks, Databricks, MongoDB have all done so well. They basically took over their open source projects and provided official vendor support in the Oracle "style".
They all offer certifications, training and conferences around the world for you to spend company money on.
Well yes, engineers do need to learn how to stand their ground - over things like pay and working conditions. But no amount of standing your ground will let you overrule the CTO on a corporate strategic decision, no matter how mistaken. As the saying goes, "God grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference."
MySQL and Postgres have multi-master replication. They do NOT have distributed transactions (with the distributed locking system etc). For some customers it is important. Others have delusions that they need it.
Oracle has other products as well. I am generally aware of couple used widely.
Their ESB is one of the heavy players, and some sausage stands always need the most advanced ones. The funny thing is that with Oracle's ESB you end up developing the missing glue features using Java, and the ESB product's framework. The environment is extremely non-productive.
Oracle's JavaEE application server is kind of nice, if you wanted WebSphere with training wheels. While feature wise it does have similar set, the maintainability and management features are just plain inferior, and most options are bolted down, and not available unless you go to lower levels...
Oh, they offer ERP suite(s) as well. Those are for people that are prone to joining religious cults. They are not technology, and software products really. They are something sold to general and logistic managers with a story that you can actually force your company to use their "best practices" sets for everything, and abandon all software architecture in favor of warm and nice spaghetti. :)
Unfortunately those are blocker level issues for most enterprisey IT managements.
Adding extra implementation to application, to do the database's work against the usual division of labor, no thanks. And bringing some shady 3rd party support package on top of the database is a second really big no.
For businesses only what you get out of the box counts. Otherwise you can always state that "the platform has C++ compiler, stfu and code". That doesn't really work. The companies are into buying complete products for a reason: they don't want to implement unnecessarily things they really should just get out of the box.
TBH I love postgres, but before they offer proper multi-master transactions out of the box most companies just still go for Oracle. That's similar as to why people buy Photoshop. GIMP fell some 10 years after in usability and features when they did not prioritize implementing the dynamic layer effect system. Instead of that they chose to masturbate with GEGL or something like that for 10 years, without providing the actual end user requested features. The situation still stands there, before they implement what Photoshop 4 or so did they got no chance of being valid alternative...
Vouching parent comment. The last time I looked at Postgres, I was really happy to see that BDR was now doable without a patched Postgres. But, I believe transactions affecting multiple tables didn't fully work yet.
Postgres is my preference over MySQL/MariaDB, but I wouldn't have pushed for it back when I worked in traditional corporate IT: Stability, and having a third-party to blame, really wins there!
Okay, sorry, you're right. In my head "multi-master" is N > 2, for some reason. Probably because of Bucardo.
Also, we're only on 9.5, so I haven't gotten to play with BDR yet, though I do have a meeting next week to start talking about how we might use logical decoding.
I may be missing something, but I don't see any mention of 2 nodes in that blog post. In fact, BDR is designed to be run with many more nodes. That being said, it's an asynchronous multi-master, suitable for geo-distributed architectures. Everyone has their own concept of what multi-master is, sadly.
The other thing is that "PG 9.6 brought ..." might suggest this is built into PostgreSQL 9.6. That's not quite the case - we're working on moving it into core, but that takes time. For now it's an extension (plug-in). PG 10 will however include pglogical, which is another step in that direction.
> Oracle's JavaEE application server is kind of nice
You mean Weblogic, right? Because OAS has been dead for a while now. Afaik, Weblogic and Websphere are practically the same, hard to say one is "just plain inferior" to the other.
...except when it comes to support for talking with Tuxedo. I guess my shop may be one of the largest Tuxedo users in the world, so it makes WLS kind of mandatory :(
Just saying : if Oracle has proper distributed transactions, then it is lying. Welcome to CAP. Or it has times when it will shit the bed and wait. For reaaaaally long time.
Postgres has at the very least window functions. What do you mean by online reorg? Schema changes in a transaction that doesn't block? Yeah, postgres has that too.
> PL/SQL (the worst language ever but very useful for building packages inside database)
I've heard that "in the database" sentence many times but never got it. PL/SQL is just another programming language VM that happens to have SQL types as native types, and syntax for SQL cursors.
Other than for triggers and possibly indexed deterministic functions (both of which are inessential/questionable), you don't want your code "in the database" due to it lacking basic capabilities such as unit testing.
There are several unit testing frameworks for PL/SQL. Code in the database encapsulates business logic, it gives you unified access from all clients. It can also be orders of magnitude faster. The presentation linked here
The performance argument I can accept (I've done PL/SQL coding and administered Oracle clusters years ago). But when it comes down to it, PL/SQL can possibly only benefit from lower inter-process or JDBC driver overhead vs. Java, say. I've seen PL/SQL becoming a CPU bottleneck in large real-time migration projects.
To encapsulate business logic using PL/SQL, however, is crazy IMHO. Rather than coding your business logic in a mainstream language (with incomparably better staffing and tooling), you now have it in a proprietary niche language with awkward or even non-existent debugging.
Also, the relational model is (or should be) the unified access at this level IMHO, rather than some ad-hoc data access layer.
The Oracle database is a beast, both in terms of performance, performance tuning and features.
It probably out performs MySQL and Postgres in most areas - and if you don't do horizontal scaling, then Oracle is probably your best bet if you want to get the most out of a server.
I don't think there are any advantages of going to vertical scaling over horizontal scaling these days.
Relational databases don't scale horizontally all that far because of the challenges in replicating writes. Either you do delayed replication and have inconsistent slaves, or you do sharding and have a complicated app layer.
The trick to scaling a sql db is to either shard it and treat it like nosql with worse tooling, or go vertical as far as you can before you go horizontal. Luckily, there aren't many workloads that require horizontal scaling. Stackoverflow can run on a single beefy db server.
Vendor locked. Many companies have huge applications bound tightly to the Oracle database. Often the business logic is just stored procedures. That makes it incredibly difficult to migrate and developers will have a hard time convincing management that the cost of migration would be worth it.
Main reason that I have seen for Oracle is that businesses buy applications and then install the database they need to run that application. How many ERP/CRM/HR/financials applications are there that compete with Oracle applications that run on MySQL or Postgres?
This is correct. If a major ERP/CRM player used Postgres it would be different. I guess a lot of that is down to the slow development cycle of those products.
It wont be SAP though, they seem to be all about HANNA these days
It's not support, it's blame. When the fertilizer hits the circular air moving device someone needs to be the scapegoat. And believe me, the CIO is not going to be the one. There isn't an entity to point to if you run MySQL or PostgreSQL.
Qualify "people". For many classes of enterprise applications (BI etc), mysql and postgres are not even a choice, it's all about oracle/sql server/db2.
Pg and mysql dominate developer-centric operations, but business-first environments are a very different game. There, it's all about long sales cycles and long feature-lists that only big vendors can afford.
MySQL support you can get from Oracle. PostgreSQL support is very limited.
There is no vendor so you're relying on third parties many of whom are mom and pop shops. And if you're a global, multi-national well good luck finding someone who you can cut a deal with for global support. Not to mention that the support is hardly likely to be top tier.
You say this garbage every time this comes up. "Mom and pop shops". Yes, those exist, but they're the minority.
You're generally either dealing with EnterpriseDB, or you're dealing with a company that is run by people who are significant contributors to the project — literally, on the core committee — or have people who have created meaningful parts of the PostgreSQL ecosystem.
You need to drop this FUD.
I will never again use or support an Oracle product after they literally, specifically cost a former employer $.75mm, on Cyber Monday by giving us factually false information.
If they actually did consider it, legal would probably make them unconsider it. That is, after laughing in such a way as to give the C*O the impression someone has just walked on their grave.
I say this "garbage" because in my opinion it's true.
EnterpriseDB has according to LinkedIn between 200-500 people mostly located in AMR and EMEA based on experience with their APAC division. They simply are NOT a top tier support company on par with Oracle, Teradata, SAP etc. I am based in APAC and so my opinion is going to be far different than other parts of the globe.
And the difference with DataStax, MongoDB etc is that those companies are basically the open source projects. They control the steering committees, copyrights, branding etc. And so there there's a lot more confidence in being able to reach someone who actually wrote that part of the code. PostgreSQL has always been far more decentralised.
EnterpriseDB has multiple pg core devs on staff and has been offering excellent pg support for over a decade. A former employer used them and they lived up to their reputation -- very good, not cheap (but cheap compared to Oracle.) I can't imagine they have any trouble selling the usual 30m or 60m SLA contracts into APAC, but maybe I'm wrong. For companies in EMEA or North America they're an excellent choice.
You don't choose Oracle databases. You choose Oracle products and services that use Oracle databases. If you visit their website and hover over the products and solutions tabs you'll see a ton of boring mission critical applications that most startups will never touch.
Oracle is much better at handling huge amounts of data. Oracle also has support for all kinds of really niche features that are really important to some people.
But hyper threading doesn't really double the performance of the CPU, I understood it's a marginal improvement. It seems odd to double the cost of the license if hyper threading is switched on.
It's a thin fig leave for "we don't care, but do it anyway". Their grandiose cloud plans tanked hard, they screwed up all products they bought, now with their backs against the wall the only thing left is milking existing customers at any cost. It's obviously a last resort short-term strategy.
HT performance grew from generation to generation. In many cases a HT "core" has 80% of the performance of a "normal" core. A current 2-core+HT i3 CPU is almost on par with a 4-core i5 (the i3 has faster cores but less L3 cache).
I guess it must really depend on the task. My basic understanding of hyper threading is that it is typically useful in memory intensive applications, where the core spends a lot of time (20ish cycles) waiting to get data from RAM. HT then executes the other thread while waiting.
As I understand HT, in it's most basic form it will try to utilize all processing units by executing code from a second thread whenever possible. FFMPG most likely maxes out usage of all arithmetic and floating point units and limits branching to a minimum, so it would make sense that there are no real performance gains with HT.
For any kind of branchy pointer-chasing workload hyperthreading will easily double the throughput. These workloads spend all of their time waiting for load and recovering from mispredicted branches. Oracle is the poster child of this kind of workload.
For decades now we've had to suffer these weird internet arguments about whether hyperthreading is "real", as if there was a naturally-occuring correct number of frontends on a CPU. If someone wants to put more instruction decoders on their CPU there is no rational argument that is "wrong".
Of course. The question is, what is the kind of load in which it delivers 80% over a non HT core, as the GP claims? I've certainly never seen this kind of load.
This is a plain attack on Amazon, which Oracle now sees as a competitor, that will hit customers in the crossfire. I guess Oracle expects customers will simply move to Azure, since retooling ops might be easier than rebuilding solutions on other databases.
It will yet again hurt their image though; they've been hated by geeks for ages, but they are increasingly unpopular even among executives. How long can you do business with people who openly despise you?
I would guess that Oracle isn't expecting their customers to love from AWS to Azure. They are expecting they move to Oracle Cloud. I didn't see any mention of that in the original article but I wouldn't doubt those rules either didn't apply or could be bypassed by your friendly Oracle sales person if you wanted to get a taste of the Oracle Cloud.
Azure has always been charged at "1 core = 1 Oracle Processor" so this new scheme only harmonizes licensing on Azure and AWS. It's still double of on-premise pricing.
A huge lock-in for Oracle is packages. Packages make it easy to organize functions/procedures into groups (one package per group, within the same schema).
Oracle is the only db that supports packages. Packages make migrating away very difficult. However...I don't think companies will want to migrate without package support anyhow...
The alternative to packages are schemas. One schema for every group of objects. Personally, no thanks. I cannot live without packages.
Oracle now owns a huge chunk of the enteprise space. They already had a significant base with their database and ERP and CRM apps. Apart from that the large multi-billion dollar acqusitions of BEA, PeopleSoft, Siebel, Netsuite and a near endless multitude of others have left them with tens of millions of high paying and locked in customers in the enteprise space.
The acquisition of NetSuite is helping them move into the midmarket. Snapping up growing companies as they outgrow Quickbooks and hopping they keep growing.
Your comment would be just as useful if you did s/morons/people/. You can highlight that it's awfully risky to pigeonhole yourself into corporate certifications, but calling people moronic isn't civil.
We've fought every kind of licensing issue you can imagine, shitty support, broken tools. A simple migration of a few hundred rows in a very simple table turned into a month long exercise that required 200 billable hours to Oracle consultants because all of the import/export tools that Oracle provides are broken in subtle, different and incompatible ways. At one point we saved time by copying and pasting data from one table into another through the management GUI rather than fight all the bullshit Oracle puts in your way.
The customer, now irate that we've been in standstill for a year, doesn't understand and hasn't made any progress in getting Postgres signed off on by their security idiots and now they're out an extra million dollars or so.
From initial install to development to deployment it's been a nightmare and the only conclusion anybody can reasonable come up with is that it's because Oracle purposely breaks their software in subtle ways so that the only paths of execution require deep Oracle lore that only somebody who dedicates their job to being an Oracle DBA could possibly know.
Oracle can't die fast enough as a company. They're an enormous drag on the entire technology industry and I'm convinced a force for evil.