Best practices for migrating an Oracle database to Amazon PostgreSQL
aws.amazon.com
aws.amazon.com
If switching to IBM and DB/2 is a relief, the "Oracle Problem" must have been really painful.
Since oracle changed the release schedule to be a thinly veiled "pay us money or upgrade your JDK every couple months" model, there is a lot of uncertainty in javaland.
If you think that corporations would just stay up to date... well, then you clearly don't know how slow corporations are to adopt new JDKs.
The problem with Android was that it was using, Harmony, a clean-room implementation of JDK whose license is incompatible with OpenJDK. It was believed at the time that APIs were not copyrightable, and thus that clean-room implementations were not derivative works. The courts disagreed. Now Google just uses OpenJDK for Android and they are back in the clear again.
[1] https://www.geekwire.com/2017/legendary-computer-scientist-j...
But they didn't
They have golang and dart to stand behind, they have no "need" to push Java.
Anyway, I made a promise to myself that when the project hits 300 stars I'd write tests and refactor for scalability. I need 3 more. Probably will be looking for some help if anyone's interested... https://www.github.com/seanharr11/etlalchemy
"This looks like it'll cost $3M-$5M to migrate away from Oracle. But Oracle only increased our licensing costs $500K per year and I already have a team of 5 Oracle DBAs!"
Okay... but those costs compound each year.
Don't get me wrong... I'm all in the "migrate to cloud" camp. But DB migration is one of the most difficult and political conversations to have these days.
replace nvl with coalesce
replace rownum <= 1 with LIMIT 1
replace listagg with string_agg
replace recursive hierarchy (start with/connect by/prior) with recursive
replace oracle insensitive query format with insensitive_query()
replace minus with except
replace SYSDATE with CURRENT_TIMESTAMP
replace trunc(sysdate) with CURRENT_DATE
replace trunc(datelastupdated) with DATE(datelastupduted) or datelastupdated::date
replace artificial date sentinels/fenceposts like to_date(’01 Jan 1900’) with '-infinity'::date
remove dual table references
replace decode with case statements
replace unique with distinct
replace to_number with ::integer
replace mod with % operator
replace merge into with INSERT ... ON CONFLICT… DO UPDATE/NOTHING
change the default of any table using sys_guid() as a default to gen_random_uuid()
oracle pivot and unpivot do not work in postgres - use unnest
ORDER BY NLSSORT(english, 'NLS_SORT=generic_m') becomes ORDER BY gin(insensitive_query(english) gin_trgm_ops)
replace UNISTR( with U&’
Oracle: uses IS NULL to check for empty string; postgres uses empty string and null are different
Fix string IS NULL comparisons: field1 IS NULL becomes COALESCE(field1::text, '') = ''
Fix string IS NOT NULL comparisons: field2 IS NOT NULL becomes (field2 IS NOT NULL AND field2::text != '')
If a varchar/text column has a unique index a check needs to be made to make sure empty strings are changed to nulls before adding or updating the column.
PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias must be provided for it. - SELECT * FROM ( ) A
Any functions in the order by clause must be moved to the select statement (e.g. order by lower(column_name))
Any sort of numeric/integer/bigint/etc. inside of a IN statement must not be a string (including 'null' - don't bother trying to use null="", it won't work).
Concatenating a NULL with a NOT NULL will result in a NULL.
Pay attention to any left joins. If a column from a left join is used in a where or select clause it might be null.
For sequences, instead of table.nextval use nextval()
Recommendation: change all varchar2 columns to be not null and set the default to be ''. This fixes a lot of the issues with the difference between how oracle and postgres treat empty strings and nulls.
>>> Pay attention to any left joins. If a column from a left join is used in a where or select clause it might be null.
For example: "replace mod with % operator", can a shim "mod" function be implemented on Postgres?
Do you think it's reasonable to lint/test your way to compatibility before transition, and then remove transitional code afterwards, or do you think it needs to be a long running fork of the codebase? We did the former for our Python 2-3 migration and it worked really well.
For me the most annoying thing has been the (+) operator for LEFT/RIGHT (OUTER) JOIN, which does not exist in PostgreSQL.
Generally speaking, PostgreSQL’s syntax feels more logical.
https://docs.oracle.com/database/121/SQLRF/queries006.htm#SQ...
I wrote an adapter that tied PHP (pre-1.0) and Java together before we had servlets and Tomcat. We used Java for the ‘backend’ and PHP for the ‘frontend’ rendering. Java talked to Oracle, pulled data out of the db and sent it to PHP for rendering the HTML. Oracle was forced on me because Ascend had a contract with them. This project was a nightmare on many levels, but Oracle was the majority of my drama.
Eventually, this project drove me to figure out servlets and Apache Jserv (first open source servlet engine)… which then led to myself and a couple random guys from Italy who had joined to work on JServ, to get Sun to open source Tomcat and create Java Apache (later renamed to Jakarta). If it wasn’t for all that, other Java stuff might not have happened at Apache (Hadoop, Lucene, etc).
Wow the guts of that thing are a god-awful mess.
Alternatively, you could pay EnterpriseDB.
It might also be reasonable to migrate what you can into ADA, and run it outside of any database altogether.
Context: https://www.webpronews.com/larry-ellison-amazon-oracle-datab...
This isn't remotely true at all. As far as I'm aware most of the work inside of aurora is in the storage side which is a complete rewrite with a new architecture as per here [1].
>Who develops Aurora? That would be Oracle. It’s called MySQL.
Christ.
1. https://www.slideshare.net/AmazonWebServices/amazon-aurora-a...
He can't even write the name correctly.
In the CAP theorem context if you need CA you can't beat an IBM mainframe. IBM can also co-locate nodes of it's latest Power9/GPU supercomputer racks.
I'm not sure if you consider that a technical, or a business justification, but I don't really see a distinction here.
Some more strictly technical justifications would be:
* Aurora has the potential to be a better architecture in the long run because it has something closer to an active/active redundancy, rather than Oracle's primary/secondary architecture, where fail-overs are manual and/or prone to failure. * Aurora can also scale out to larger database sizes than Oracle.
Now Standard Edition 2 costs $17k/core, but I believe it includes a license to use Real Application Clusters (RAC), justifying the price hike.
Not much justification if you're only running a single instance, though.
https://www.oracle.com/assets/technology-price-list-070617.p...
SE2 processor license is $17,500.
Enterprise processor license is $47,500.
So single 8 core CPU is 17500 with SE2, but 40.547500.
(Note also that if "cloud" is all you want, and you're comfortable with Oracle otherwise, Oracle is loudly touting their own.)
Oracle is also a hairy beast, kind of the perl of databases: there's always more than one way to do it.