Oracle seems just a moneygrabbing shell company at this point and I suppose the whole hyperscaler-cloud is developing towards that point with the leaders of those corporations repeating exactly the same talking points...
Not that it matters that much - there are better EPM/CPM products now available, like OneStream ;)
My personal goal was to avoid becoming an Oracle expert. (Why? Because even as someone who passed advanced Oracle training easily it was still extremely painful. One mistake towards the end of an installation could easily result in 2 days extra work to clear it out.)
Stupid as I was I said nothing about all the work we went through and only mention all the money we could save.
The response was something I learned a lot from.
It was mild and friendly and something along the lines of "here's what you don't get young lad: the customer pays for the Oracle license on top of our original price and we get a 10% cut. Changing to Postgres will effectively cost us money. Also for <this industry> when we say it is based on Oracle they feel safe."
I'm back at Oracle today after a decade of less painful options and Oracle is still painful but these days I'm not the DBA thankfully and only have to deal with connectionstrings that makes every other database look easy, different SQL syntax etc.
As Oracle is so expensive it skews the architecture decisions towards multiple apps accessing the same DB.
Rumour has it the same holds for some other types of data as well but I lack immediate experience in other areas.
With Oracle you also have a rather robust, exhaustive documentation of error messages and even obscure stuff is likely to be figured out in some forum thread by someone and an indian guy. Postgres isn't exactly bad in this area but you can run into things where you need to go deep in debugging yourself and figure out minutiae of your specific version.
Containers also remove most of the issues with running several instances in development and CI environments.
I still don't recommend anyone to pick Oracle for greenfield stuff, instead you should work around shortcomings in other database engines, but for a large organisation with certain demands that already has buyin it makes sense.
This is just on top of the general technical inferiority (eg there are no transactional schema changes, so you don't get the safe go/no-go in those when applying those as part of app deploys with a migration tool)
You need to decide if and how to perform a rollback, similar to how you would define a down() procedure in migration files. A schema change might imply changes to data, and in that case you might turn off client writes, copy the table, change it, validate, do rename dance, turn on client writes again. If it doesn't it might be much cheaper to operate on a single copy. How does Postgres decide on such strategies automatically?
If your "db cluster" is split into containers on one VM as you would do in any other cloud (because VMs are expensive), then you would have the same problem.
> encouraging monolith DB consolidation
Does it? I don't think so. I've worked with Oracle's stuff and the only real difference between Oracle Cloud and other clouds is that Oracle cloud is more expensive overall. There's nothing stopping you from running virtual machines and kubernetes in the same way you'd run it in any other cloud.
Some of the tooling around it is nice and it has some nice features but I would not recommend it even if it was free.
Edit: unless the great database is MySQL, they are actually decent stewards of it and while I still strongly prefer PostgreSQL MySQL is pretty good these days.
- institutional inertia - some weird consultant style people in key roles (this happens around cloudy stuff too) - the DBA-team - "we can't move everything!" - "we just migrated off solaris!"
however every new project with sane leadership seems to decide against oracle.
It just makes me mad.
OAM is an access management product, used to implement stuff like SSO (single sign-on). So, for example, it comes with a module you can install in Apache which will intercept HTTP requests and redirect them to OAM’s login page - which may potentially talk to an LDAP to authenticate you. Or you can do stuff like define some URL patterns in an app as sensitive so they require a more secure authentication mechanism (such as 2FA or smart card), other URL patterns as less sensitive so password-only login is sufficient
OIM is basically about provisioning accounts from a source system into target systems. Those systems could be LDAPs from various vendors, but can also be HR systems (Oracle’s various offerings and SAP too), IBM mainframes (RACF, TopSecret, ACF2), Unix/Linux hosts, database tables, custom apps… also lets you do things like setup workflows to approve system access requests, you can configure it to require reapproval of high risk access requests by management every X months or else they get revoked (used for Sarbanes-Oxley compliance), etc
Source: I used to work for Oracle Engineering, in a team which handled escalations for these products-especially OIM, but I stuck my fingers in most of them. When I left (back in 2017, so a while ago now) they were putting a lot of effort into their cloud offering (IDCS, more recently replaced by OCI IAM), but I’m sure the on-premise offerings are going to stick around for a long time, especially because they have some customers (e.g. in the national security space) for which cloud is unlikely to be a viable solution any time soon