search

oracle / oracle-database-operator

The Oracle Database Operator for Kubernetes (a.k.a. OraOperator) helps developers, DBAs, DevOps and GitOps teams reduce the time and complexity of deploying and managing Oracle Databases. It eliminates the dependency on a human operator or administrator for the majority of database operations.
Universal Permissive License v1.0
141 stars 45 forks source link

SingleInstanceDatabase listener has empty list of services #92

Closed ilfur closed 4 months ago

ilfur commented 7 months ago

It has been hard to reproduce, but one of my customers is oerceiving problems with SingleInstanceDatabase setups. After the database has been created , he could not connect to it from external tools like sql*plus even though the network connectivity was working. The error message received was ORA-12514, TNS: listener does not currently know of service And checking with "lsnrctl status" inside the database pod gave an empty list of database services.

So the database instance was unable to register itself with the database listener. Manually configuring the LOCAL_LISTENER parameter of the database instance to a value of (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=0.0.0.0)(PORT=1521))) and then registering the database again with the listener worked, the listener showed the database service and sql*plus was able to connect to the database instance.

After some research, he found out that the database instance tries to register itself to a listener running on the hostname of the current host. This would be the name of the database POD, but not necessarily the name of the kubernetes service pointing to the POD. So a name resolution would fail, database registration would fail.

Since this is not always a problem but the cure to set this parameter would always help (except for data guard configurations where we may need a REMOTE_LISTENER), owuld it be feasible to You to permanently add this parameter through the OraOperator when setting up a new SingleInstanceDatabase resource ?

Any response is greatly appreciated ! Oh BTW, the platform in use here is OpenShift. If that helps (different POD naming strategy perhaps? )

ilfur commented 4 months ago

Found out that in cases I tested, I just was not patient enough. Database startup occurring, recovery perhaps, or patching. After a while, the database services DID register with the listener. I think this SR can be closed.

ilfur commented 4 months ago

Patience is a virtue ...

yunus-qureshi commented 4 months ago

Thanks @ilfur for checking and getting back on this