Init SQL script in /container-entrypoint-initdb.d folder didn't get executed

[sixth-instinct]

Hi Gerald,

This question refers to your Docker image for Oracle XE at https://hub.docker.com/r/gvenzl/oracle-xe.

I put an init or setup .sql file in the /container-entrypoint-initdb.d folder through a Docker volume, but it did not get executed.

When I ran "docker-compose up", the log showed that the database was already initialized. Could that be the reason it skipped my init SQL script?

orax21c | CONTAINER: starting up... orax21c | CONTAINER: database already initialized. <<--------- orax21c | CONTAINER: starting up Oracle Database...

If I moved my SQL script to the /container-entrypoint-startdb.d folder through a Docker volume, it got executed after the database startup (not init) as expected.

So how could I get my init SQL file to be executed during the database initialization?

Could I add the following SQL statements to my init SQL script?

1. Create tablespace
2. Create profile
3. Create role
4. Grant ... to role

Are the scripts in the /container-entrypoint-initdb.d folder supposed to get executed every time the Docker container is created?

If that's the case and the Oracle data (/opt/oracle/oradata) is made persistent through a Docker volume, would the init script create an error because it's trying to create something (e.g. a tablespace, a profile, a role) that already exists?

I'm currently using image gvenzl/oracle-xe:21.3.0.

Thank you.

chris

[gvenzl]

Hi @sixth-instinct,

Thank you very much for using these images!

The scripts in /container-entrypoint-initdb.d are only executed after the database initialization, see here:

Note: scripts in /container-entrypoint-initdb.d are only run the first time the database is initialized; any pre-existing database will be left untouched on container startup.

As you already observed, the database was already initialized, because the container had a volume with existing database files mounted. Just as you said, if these setup scripts would run again every time a new container is started with an already existing database, the scripts would fail because they would try to create objects that were already created beforehand.

On the other hand, scripts in /container-entrypoint-startdb.d will be executed every time after the database has been started, i.e. with every new container that has been started up.

/container-entrypoint-initdb.d should be used for the initial setup of the database environment, all the things that need to be executed once at the beginning so that the database is ready for use. Like you have above, creating tablespace, users and PDBs, or an application schema.

/container-entrypoint-startdb.d should be used to (re)set runtime specific variables. Perhaps set localization settings or similar.

Hope this helps!

[glelouet]

you can also use that startdb script to add more import with the --nowait in the dockerfile

RUN ["container-entrypoint.sh", "--nowait"]

(then you must remove them or use a multi stage docker image)