ORA-12514 while connecting to DB on Docker via Gitlab CI Pipeline
phisii opened this issue · comments
Hello,
first I want to thank @gvenzl for providing these images. They are very helpful for us.
We want to use a Oracle DB for automatic testing on our Gitlab CI Pipeline. We have a Java-Spring application that wants to connect to a Oracle 11 Database.
On our local systems everything works without a problem, but when we try our image on the CI we get the error:
Caused by: oracle.net.ns.NetException: Listener refused the connection with the following error:
ORA-12514, TNS:listener does not currently know of service requested in connect descriptor
We use a self build image based on the Oracle 11 Images:
(We choose to create our own image because we need to import a big dataset, which is to large for importing on every start. For this we use the entrypoint scripts.)
(Usernames, passwords, .. set like this for display reasons).
FROM gvenzl/oracle-xe:11-full
ENV ORACLE_PASSWORD=Pw
ENV APP_USER=User1
ENV APP_USER_PASSWORD=Pw
USER root
RUN microdnf install java-11-openjdk-headless -y
ENV JAVA_HOME /usr/lib/jvm/jre-11-openjdk
RUN microdnf install maven -y
RUN microdnf clean all
USER oracle
WORKDIR ${ORACLE_BASE}
COPY DBDump.DMP /u01/app/oracle/admin/XE/dpdump/DBDump.dmp
COPY scripts /container-entrypoint-initdb.d
RUN container-entrypoint.sh --nowait \
RUN echo "Stopping database..." && \
echo "shutdown immediate;" | sqlplus -s / as sysdba && \
lsnrctl stop
EXPOSE 1521
Our import scripts:
1-setup-db.sql:
CREATE TABLESPACE Tb1 DATAFILE 'Tb1.dbf' SIZE 100m AUTOEXTEND ON next 100m;
CREATE TABLESPACE Tb2 DATAFILE 'Tb2.dbf' SIZE 100m AUTOEXTEND ON next 100m;
CREATE USER User1 IDENTIFIED BY Pw;
GRANT CREATE SESSION TO User1;
GRANT CREATE ANY TABLE TO User1;
GRANT CREATE ANY VIEW TO User1;
GRANT DATAPUMP_EXP_FULL_DATABASE TO User1;
ALTER USER User1 quota unlimited on Tb1 ;
ALTER USER SYSTEM quota unlimited on Tb1;
2-import-dump.sh:
(We had a problem with the impdp command, but fixed thanks to this thread: #156)
export ORACLE_PDB_SID=XE
impdp System/Oracle DUMPFILE=DBDump.dmp DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS IGNORE=Y || true
When starting the container local a connection from outside the container is possible. Also we tried to get our program files into the image and starting the tests in the container, everything works fine.
But on the Gitlab Pipeline we get the ORA-12514 error.
Our connection string (localhost or the container hostname when used as service):
jdbc:oracle:thin:@localhost:1521/XE
Startup log of DB:
CONTAINER: starting up...
CONTAINER: database already initialized.
CONTAINER: starting up Oracle Database...
LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 19-SEP-2023 15:53:26
Copyright (c) 1991, 2011, Oracle. All rights reserved.
Starting /u01/app/oracle/product/11.2.0/xe/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 11.2.0.2.0 - Production
System parameter file is /u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora
Log messages written to /u01/app/oracle/product/11.2.0/xe/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date 19-SEP-2023 15:53:26
Uptime 0 days 0 hr. 0 min. 0 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Default Service XE
Listener Parameter File /u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora
Listener Log File /u01/app/oracle/product/11.2.0/xe/network/log/listener.log
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
ORACLE instance started.
Total System Global Area 801701888 bytes
Fixed Size 2230776 bytes
Variable Size 230688264 bytes
Database Buffers 566231040 bytes
Redo Buffers 2551808 bytes
Database mounted.
Database opened.
CONTAINER: WARNING: $ORACLE_PASSWORD has been specified but the database is already initialized. The password will be ignored.
CONTAINER: WARNING: If you want to reset the password, please run the resetPassword command, e.g. 'docker|podman exec <container name|id> resetPassword <your password>'.
#########################
DATABASE IS READY TO USE!
#########################
We would be thankful for any ideas. Thanks.
Hi @phisii,
Thanks a lot for using these images to extend your CI/CD workflows!
Hm, ORA-12514 usually means either a typo in the service name or that the service is not yet registered with the Listener.
However, the service itself is registered when the database is started up, i.e. once you see DATABASE IS READY TO USE!.
From above, everything seems correct, the only thing I can think of and have seen in the past is that the app tries to connect before the database is fully started.
Do your tests wait/check for DATABASE IS READY TO USE!?
If not, you may run into a race condition and the service is indeed not yet registered with the Listener by the time the app is trying to connect to the database.
Thanks for the response. We are still searching for a solution.
Yes, we are waiting for the database to startup. Our logs also show this.
We also tried the Oracle 21 Images and your new Oracle 23 Free Images as Base Image (with the appropriate connection strings with "/XEPDB1" and "/FREEPDB1"), but still got the same error.
The issue #126 seems somewhat similar to our problem.
We are working in a large enterprise IT infrastructure, so we don't have direct access to the Gitlab Runner/Docker settings, and can not easily test the suggested solutions. But we will further investigate this.
Hey @phisii,
I think I missed a crucial part of your first message:
When starting the container local a connection from outside the container is possible. Also we tried to get our program files into the image and starting the tests in the container, everything works fine.
Given that everything works fine locally and inside the container, it would suggest that the issue isn't so much with the Listener/container itself, but getting to wherever the container is running.
Could it be perhaps a firewall/config issue (I know you just said that getting to the Docker settings, etc. is hard because of the enterprise IT infrastructure)?
Is there any way for you to spin up a container on some other machine and see whether you can connect to that, outside of GitLab?
If so, that would suggest the issue is isolated to the GitLab CI/CD environment.
Hope this helps.
Today I spent like 4 hours around ORA-12514 error.
(at least in my case) it is a server issue.
When I run the server using:
docker run -it --network=host -eORACLE_PASSWORD=atk4_pass gvenzl/oracle-xe:21-slim
I always get the ORA-12514 error when I try to connect from OCI client or via sqlplus executable.
The fix is to run the server using:
docker run -it -p 1521:1521 -eORACLE_PASSWORD=atk4_pass gvenzl/oracle-xe:21-slim
Notice the --network=host vs. -p 1521:1521 difference. I can reproduce it repeatably. I also tried to spin MySQL, PostgreSQL, MSSQL server containers and none of them suffer this issue. A listening port on *:1521 is opened correctly + DATABASE IS READY TO USE! is shown in both cases.
The question is, why with --network=host the Oracle server cannot be accessed? Is this something that can be fixed?
Hi everyone,
@gvenzl thanks for the input:
We were able to set up a local runner on our own PC, there the Image and Connection to the application is running without the problem (So Gitlab does the same thing, just on our PC instead of the cloud instances, and it's working). We are now talking to the administration of the cloud environment, to find out what the issue is.
Will keep you updated, if we find something.
@mvorisek interesting, thanks. But I don't know if this is relate to our problem. I couldn't replicate it on my pc.
Managed to get this working on the CI pipeline referenced above by adding .WithHostname("localhost") (this is TestContainers.Net using the image).
I was seeing a strange ORA-12514 error message Service XEPDB1 is not registered with the listener at host 127.0.0.1/127.0.0.1 - that "127.0.0.1/127.0.0.1" at the end was bugging me, so on a bit of a whim I tried setting localhost and it worked.
It's worth saying the original code worked fine on my desktop and laptop, like the original issue this was only failing on the CI runner (I don't know the specifics of the setup there).