Startup scripts not being run in Oracle Docker container

[michny]

I have issues with startup scripts not being run when I start an Oracle docker container.

I have pulled the Docker image container-registry.oracle.com/database/enterprise:latest and started it using the command docker run -d --name oracle-db2 -p 1521:1521 -e ORACLE_PWD=admin1234 -v C:/Source/dummyscripts:/opt/oracle/scripts/startup container-registry.oracle.com/database/enterprise:latest. The folder "C:\Source\dummyscripts" contains a SQL script called 01_local-oracle-setup.sql which executes a CREATE USER, CONNECT (as that user), CREATE TABLE and INSERT (into created table) statements. The script works just fine when run through SQL Developer against an oracle container, so I don't imagine there is anything wrong with the script.

Starting the container with the docker run shown above successfully starts the container and I can (after some minutes) connect to it using either SQL Developer or SQLPlus with docker exec -it oracle-db2 sqlplus. But it has apparently NOT executed my script from the /opt/oracle/scripts/startup folder. At least the user and table created by the scripts are not to be found.

I don't see any reports of errors when running the docker run though, so I am not sure how to verify why it doesn't run my script. Any help would be greatly appreciated.

I have also tried using "C:\Source\dummyscripts" (the Windows version with backslash rather than forward slash) as volume, but it makes no difference.

If its of any relevance, I am running on Windows 10 and Docker Desktop for Windows and I am just trying to start the container on my local machine for now.

[sustacek]

I'd first check if your .sql actually is in the container:

$ docker exec -it oracle-19-oracledb-1 ls -la /opt/oracle/scripts/startup

If not, chances are you did not mount your host's directory into the (Linux) VM which runs Docker server for you. This happens a lot to me on Colima on OSX, when I reset it the mounts are empty.

Since you are using Windows, I bet you're running into the same. E.g. if you are using Docker Desktop, make sure the C:/Source/dummyscripts is whitelisted and available to the VM running Docker.

[michny]

I tried your suggestion and it does seem like the file is present in the container. The output of the command is:

docker exec -it oracle-db2 ls -la /opt/oracle/scripts/startup
total 12
drwxrwxrwx 1 root   root  512 Mar 10 13:54 .
drwxr-xr-x 1 oracle dba  4096 Sep 30  2022 ..
-rwxrwxrwx 1 root   root 7583 Mar 10 13:31 01_local-oracle-setup.sql

[sustacek]

Hmm, unfortunately I have no other idea what to check, sorry.

[norman-aberin]

The image I have tried is free:latest, so please note that some things may be different if anything, I would advise you to consult the documentation.

First, you can try running the following command below. For FREEDB, it would display the results of your nit script or if there are any errors. It showed whether it actually ran at all. An example output is showed below:

$ docker logs mycontainer

# output snippet
Version 23.3.0.23.09
The Oracle base remains unchanged with value /opt/oracle
#########################
DATABASE IS READY TO USE!
#########################

Executing user defined scripts
/opt/oracle/runUserScripts.sh: running /opt/oracle/scripts/startup/init.sql

Session altered.

User created.

Grant succeeded.

Grant succeeded.

Table created.

Table created.

DONE: Executing user defined scripts

Another thing to note is you should run alter session to your PDB because the init script would be run against the CDB otherwise. So to do that, initially in your sql script add the following:

-- note the following is for FREEDB, For enterprise, I think it is simply PDB1. Run a query from services to find out
alter session set container=FREEPDB1; 

[murata-kawairi-business]

What I encountered was a similar but different pattern. If I put the script in init-scripts/startup/ it runs, but if I put it in init-scripts/setup/ it is ignored. Both scripts have the alter session set container = $PDB_NAME; at the beginning of the run.

Is the root of this problem the same?

If I am out of place, please forgive me.

[yunus-qureshi]

If you are running free:latest from container-registry then this is expected. Free comes with a pre-built database and therefore just start up scripts are executed and not setup ones. If you however specify a mount for your database, then a fresh Free DB would be created and setup scripts would be executed too.