4 ms·

As someone who has never used or worked with Oracle DBs, can someone explain why migrating to another technology is so difficult? With all the database engines

As someone who has never used or worked with Oracle DBs, can someone explain why migrating to another technology is so difficult? With all the database engines available, is there really not another one that can match Oracle without massive customizations?

silon42 7y ago
It probably starts with horrible things (not SQL compatible) like "" is equal to NULL...
stickfigure 7y ago
It really depends on how your applications were designed. If you "go deep" with Oracle - and if you've hired Oracle DBAs, you probably have - you probably have a lot of your business logic buried in a large body of stored procedures that aren't version controlled and rely on Oracle-specific behavior.
ajkjk 7y ago
Oh man. I used to work at Amazon at a time when this Oracle deprecation was starting up. It's utterly non-trivial. It's not really "switching relational DBs", it's "rebuilding all of the legacy systems to not use relational DBs". Their scale had long since left the realm where it was reasonable to run everything on massive monolithic DBs, but the technical debt hadn't been paid down -- so they just kept putting more money into bigger and bigger hardware and larger DBA teams to support them. For instance when I last worked the there each warehouse ran on a single massive Oracle DB. That isn't solved by swapping to another database; it was well beyond reasonable. I suspect that this article seems like a bit of self-promotion but it's actually intended as a giant middle-finger to Oracle.
- philshem 7y ago
  > but it's actually intended a giant middle-finger to Oracle When they were all cheering, I actually felt bad for Oracle for a nanosecond.
  - tomashubelbauer 7y ago
    That sounds way too long. I think you should get that checked out.
Ygor 7y ago
In theory SQL is SQL, even more so if your App uses a layer of indirection like an ORM. If you don't use any Oracle specific features, procedures and similar, in theory you could just replace it. But that is not what happens. First problem is - majority of mature enterprise systems (which tend to use Oracle), are not designed in such a schoolbook way, so that's you first problem. Codebases are ugly and teams loose the knowledge to maintain some parts that are mature and work mostly ok - often the DB layer. Another concern is regressions in the product that is hard to properly test for. Minor details that are exposed by even small changes in DB behaviour or performance, that won't get caught in testing, but will cause an impact when your next scheduled job happens to fall on the first friday of that one month where the customer has that very special report that is just slightly so different and runs only once every 7 years. Another major pain point are operational concerns. When dealing with DB technologies, managing, deploying, operating your back end DB servers can be quite a different beast. In theory your teams should be able to handle it, as they are experienced engineers that know how to learn new tech quickly. In practice, you don't have money for those, and your team is lazy and doesn't really want to learn that new cool tech, just let them do their job. And finally, if it all "just works" at the moment, it is a hard sell to switch such a fundamental part of the system and properly validate the investment versus the risks. And this is all if you're not a super user of Oracle specific pieces, surrounding tooling or consultants/expertise.
- jodrellblank 7y ago
  In practice, you don't have money for those, and your team is lazy and doesn't really want to learn that new cool tech, just let them do their job. In practise, you want to cheap out on paying for training, have your team do their job and learn an entirely new system to expert level at the same time, the "cool new tech" isn't and your team knows that you're trying to sell it as "cool" to pull a fast one on them because you think they're idiot children, and you won't even commit to using it for long enough to make it worth the bother of trying to learn before changing your mind or prioritising something else, and you're humming and hawing about investing in the tools to make the new tech work well because it's free software so why should it cost you any money? Besides, you won't prioritise maintenance or design, so the codebase is a mess and people are incentivised towards panic-of-the-day fixes and don't-ever-ever-break-anything conservatism - their fault not yours, obviously, it can't be your fault, you don't even work with the tech (you just choose it by fiat).
raincom 7y ago
I used to write PL/SQL long time back. In old days, every business logic was written in stored procedures, which the java code calls. Migrating stored procedures is a hard part since whoever wrote it left the company long time ago. Whatever talent available in the company that wants to migrate off Oracle, would not want to take the risks of migration failure.
forinti 7y ago
When you have an Oracle database, you probably have a lot of PLSQL. That, in itself, is not so serious (PgPLSQL is quite similar). But you'll probably have Forms, Reports, and Apex too. These are all designed to make building an app a piece of cake but make it impossible to migrate except if you rewrite the whole thing.

silon42 7y ago

It probably starts with horrible things (not SQL compatible) like "" is equal to NULL...

stickfigure 7y ago

It really depends on how your applications were designed. If you "go deep" with Oracle - and if you've hired Oracle DBAs, you probably have - you probably have a lot of your business logic buried in a large body of stored procedures that aren't version controlled and rely on Oracle-specific behavior.

ajkjk 7y ago

Oh man. I used to work at Amazon at a time when this Oracle deprecation was starting up. It's utterly non-trivial. It's not really "switching relational DBs", it's "rebuilding all of the legacy systems to not use relational DBs". Their scale had long since left the realm where it was reasonable to run everything on massive monolithic DBs, but the technical debt hadn't been paid down -- so they just kept putting more money into bigger and bigger hardware and larger DBA teams to support them. For instance when I last worked the there each warehouse ran on a single massive Oracle DB. That isn't solved by swapping to another database; it was well beyond reasonable. I suspect that this article seems like a bit of self-promotion but it's actually intended as a giant middle-finger to Oracle.

philshem 7y ago
> but it's actually intended a giant middle-finger to Oracle When they were all cheering, I actually felt bad for Oracle for a nanosecond.
- tomashubelbauer 7y ago
  That sounds way too long. I think you should get that checked out.

Ygor 7y ago

In theory SQL is SQL, even more so if your App uses a layer of indirection like an ORM. If you don't use any Oracle specific features, procedures and similar, in theory you could just replace it. But that is not what happens. First problem is - majority of mature enterprise systems (which tend to use Oracle), are not designed in such a schoolbook way, so that's you first problem. Codebases are ugly and teams loose the knowledge to maintain some parts that are mature and work mostly ok - often the DB layer. Another concern is regressions in the product that is hard to properly test for. Minor details that are exposed by even small changes in DB behaviour or performance, that won't get caught in testing, but will cause an impact when your next scheduled job happens to fall on the first friday of that one month where the customer has that very special report that is just slightly so different and runs only once every 7 years. Another major pain point are operational concerns. When dealing with DB technologies, managing, deploying, operating your back end DB servers can be quite a different beast. In theory your teams should be able to handle it, as they are experienced engineers that know how to learn new tech quickly. In practice, you don't have money for those, and your team is lazy and doesn't really want to learn that new cool tech, just let them do their job. And finally, if it all "just works" at the moment, it is a hard sell to switch such a fundamental part of the system and properly validate the investment versus the risks. And this is all if you're not a super user of Oracle specific pieces, surrounding tooling or consultants/expertise.

jodrellblank 7y ago
In practice, you don't have money for those, and your team is lazy and doesn't really want to learn that new cool tech, just let them do their job. In practise, you want to cheap out on paying for training, have your team do their job and learn an entirely new system to expert level at the same time, the "cool new tech" isn't and your team knows that you're trying to sell it as "cool" to pull a fast one on them because you think they're idiot children, and you won't even commit to using it for long enough to make it worth the bother of trying to learn before changing your mind or prioritising something else, and you're humming and hawing about investing in the tools to make the new tech work well because it's free software so why should it cost you any money? Besides, you won't prioritise maintenance or design, so the codebase is a mess and people are incentivised towards panic-of-the-day fixes and don't-ever-ever-break-anything conservatism - their fault not yours, obviously, it can't be your fault, you don't even work with the tech (you just choose it by fiat).

raincom 7y ago

I used to write PL/SQL long time back. In old days, every business logic was written in stored procedures, which the java code calls. Migrating stored procedures is a hard part since whoever wrote it left the company long time ago. Whatever talent available in the company that wants to migrate off Oracle, would not want to take the risks of migration failure.

forinti 7y ago

When you have an Oracle database, you probably have a lot of PLSQL. That, in itself, is not so serious (PgPLSQL is quite similar). But you'll probably have Forms, Reports, and Apex too. These are all designed to make building an app a piece of cake but make it impossible to migrate except if you rewrite the whole thing.