Just in time for KubeCon in London, the OraOperator update 1.2 for almost any Kubernetes distribution was released in March 2025. I would like to briefly point out the most obvious and long-awaited innovations and changes.
The Oracle Database Operator for Kubernetes, or OraOperator for short, continues to simplify the integration and management of external Oracle databases in various Kubernetes environments, including for better DevOps. It has also long been able to simplify the operation of various versions of Oracle databases and their surrounding components such as ORDS, Data Guard and monitoring metrics directly in the Kubernetes cluster. In the new version 1.2, some preview features of the previous version have been deepened and improved, but new features have also been added.
A complete list of all supported database features and variants can be found on the OraOperator documentation page on github. The same document also contains an impressive list of the new features in database lifecycle and an updated ORDS lifecycle management in version 1.2
As a component developed and maintained by Oracle, OraOperator has now received its own ID (14423 “onprem”) on the Oracle Support pages, but of course there is also a response to github issues since the developer and support teams behind OraOperator monitor both repositories.
OraOperator is now available (albeit still in version 1.1) on the Operatorhub.io website with a list of all managed resources and simple installation instructions. The Operator Lifecycle Manager (OLM), which is responsible for managing the now numerous Kubernetes operators, now also handles the setup and automatic updates of the OraOperator. In combination with functional tests on the free Openshift counterpart OKD, even more comprehensive support for Kubernetes distributions in various clouds such as Google, Azure, OCI and, of course, on-premises is guaranteed.
Pluggable databases (PDBs) can and may be referenced externally (e.g. on separate database servers such as Exadata and Database Appliance) as well as being operated directly in the Kubernetes cluster. OraOperator takes care of the lifecycle management of PDBs and can create, clone, reconfigure, start up, shut down and, of course, delete them from a single source together with an application deployment. In the new version 1.2 of the OraOperator, PDBs no longer have to be managed via the REST services of an automatically provided ORDS container. This is due to a new controller for PDB lifecycle management. So the conventional Kubernetes resources CDB and PDB could be replaced by LREST and LRPDB Kubernetes resources. LREST is a separate, particularly lean container that deals exclusively with the lifecycle management of PDBs and connects to a container database (CDB).
This eliminates the dependency on certain, mostly older and self-built ORDS containers, and there are also no conflicts with ORDS-specific database schemas of different versions in a CDB with those in individual PDBs. Looking under the hood, many other manageability problems that you may have already encountered have also disappeared. Furthermore, new features are now possible such as binding to existing PDBs and a planned future auto-bind or auto-discovery of all PDBs of a CDB. Instructions for setting up the new LREST and LRPDB resources can also be found on github.com in the Multitenant support section.
Support for Data Guard in databases within the Kubernetes cluster (the SingleInstanceDatabase Kubernetes resource), which was previously marked as a developer preview, has now reached production status with version 1.2. The difference is a built-in observer that supports the Fast Start Failover feature (FSFO) of mirrored Oracle databases. Before version 1.2 of OraOperator, only manual switchovers to mirrored databases were possible, for example to enable zero-downtime patching of entire databases. Now, unplanned failures are also supported thanks to FSFO. And mirror databases can be put into snapshot standby mode so that developers can temporarily run tests on a mirror database.
pre-started containers for quicker failover or Data Guard with mirrored data files,
now also including fast-start failover (FSFO) and snapshot standby mode.
But even more has happened in the area of high availability for in-cluster databases. OraOperator can provide you with massive support in setting up a Globally Distributed Database (once also called a Sharded Database). In a Globally Distributed Database, parts of the data are outsourced to separate databases. These databases are united by a coordinator so that operations on the data are automatically distributed and the otherwise self-sufficient Oracle databases (in the role of shards) act as a single database. However, this is heavily distributed across different nodes and perhaps also across different networks. Oracle 23ai added another feature, Raft Replication. It is now also supported by OraOperator and enables data synchronization between individual shards.
In principle, this sync leads to a similar data distribution as with a RAID 1+0 hard disk system, but runs via the Raft consensus protocol across a network. The Raft Sync does not require a Data Guard or GoldenGate and promises database (or shard) failover times of less than 3 seconds. For systems with more than 3 shards, you need Active Data Guard or GoldenGate licenses, but not the technology behind them. Why don’t you try such a setup in your Kubernetes cluster? You can also find a description using the Oracle23ai free database as an example on github. General information on Raft replication is available as a Blog entry and also as a Youtube video.
Support for the True Cache mechanism based on Oracle Data Guard has also been added, albeit initially only as a Developer Preview feature for 23ai FREE databases for testing. For further innovations in existing features, please refer to the now comprehensive documentation on github, or some blogs on OraOperator to support ORDS containers and grafana metrics, for example.
As always, have fun testing and trying them out!
Some fo the links in this blog post:
The source page of OraOperator on github with a list of all features and supported cloud and onprem variants
OraOperator on Operatorhub.io and Artifacthub.io
Operating an in-cluster Oracle Database with grafana monitoring
OraOperator and the new LREST multitenant support on github
OraOperator and TrueCache support on github
Globally Distributed Database and raft replication with Oracle Database 23ai