Comment by bane | Hacker News Reader

Comment by bane | Hacker News Reader

Parent Full thread

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.

In a sense, it's become the 21st Century version of the old IBM meme: "Nobody ever got fired for buying IBM."

Oracle is shit, but sounds like you should have used it from the start if the client didn't approve PostgreSQL.

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.

I heard once that they actually try to dumb down the books they publish so that people will need to pay Oracle for more support.

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.

I have a MYSQL and MSSQL background. I never understood everyone's fear of using CLOB/BLOB data types. Then I started working Oracle.

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.

Even if this is true, it kind of misses the point. There's no reason such a simple task should require this much knowledge in the first place.

> 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.

There's a phrase to describe things that require you to understand how they internally work: leaky abstraction.

It sounded like you were trying to defend the Oracle product here, but it actually comes across as a sort of indictment.

Similar just exchange postgre with MySQL.... For a fucking simple CMS! Not even Mission critical! But they demand oracle..

What a great takedown, couldn't agree more

Reply on news.ycombinator.com