dpdump deleted on initial startup

[AlBundy33]

with this docker-compose file the dumps in the dpdump-folder will be deleted on first startup.

services:
  oracle:
    image: container-registry.oracle.com/database/express:21.3.0-xe
    ports:
      - "1521:1521"
      - "5500:5500"
    environment:
      - ORACLE_PWD=oracle
    volumes:
      - ./oradata:/opt/oracle/oradata
      - ./startup:/opt/oracle/scripts/startup
      - ./setup:/opt/oracle/scripts/setup
      - ./dpdump:/opt/oracle/admin/XE/dpdump

folders are owned by 54321:54321

[oraclesean]

@AlBundy33 the path set for the dpdump folder references a directory that already exists in the container image. When the container mounts the directory, its contents overwrite whatever is in the image. You could try something like:

    - ./dpdump:/opt/oracle/admin/XE/dpdump/newdir

or:

    - ./dpdump:/dpdump

These reference directories that don't exist in the image and therefore aren't overwritten.

[AlBundy33]

but there was an error from rm on startup and afaik docker does not deletes volumes because this would mean that your volumes get deleted on each startup

[AlBundy33]

because I've used an image from docker registry I'm not sure that this is the right repo for this issue

[oraclesean]

@AlBundy33 Docker won't delete the contents of the volume. When you mount a volume to an existing directory, the contents of the directory in the image are replaced by the mounted volume. But neither of those situations explains the lost files. My first thought was that you had something in your scripts or startup directory that was clearing the directory, so I ran an experiment.

I created directories on my system and added a file:

# touch /oradata/ORCL21XE/dpdump/test.dmp

# ls -l /oradata/ORCL21XE/dpdump/test.dmp
-rw-r--r--. 1 oracle oinstall 0 Mar 10 17:29 /oradata/ORCL21XE/dpdump/test.dmp

The file is present, so I created a new container:

docker run -d --name ORCL21XE \
       -v /oradata/ORCL21XE/data:/opt/oracle/oradata            \
       -v /oradata/ORCL21XE/startup:/opt/oracle/scripts/startup \
       -v /oradata/ORCL21XE/setup:/opt/oracle/scripts/setup     \
       -v /oradata/ORCL21XE/dpdump:/opt/oracle/admin/XE/dpdump  \
       container-registry.oracle.com/database/express:21.3.0-xe

After it started, the above file was indeed gone. I checked the logs and saw that the Database Creation Assistant (DBCA) is responsible:

opt/oracle/cfgtoollogs/dbca/XE/trace.log_2025-03-10_05-32-47PM:[progressPage.flowWorker] [ 2025-03-10 17:32:54.546 UTC ] [Host.setUpForOperation:4380]  creating directory:/opt/oracle/admin/XE/dpdump
<snip>
opt/oracle/cfgtoollogs/dbca/XE/trace.log_2025-03-10_05-32-47PM:[progressPage.flowWorker] [ 2025-03-10 17:32:54.546 UTC ] [Host.setUpForOperation:4399]  Folder:/opt/oracle/admin/XE/dpdump is on acfs =false

The dpdump directory is created by Oracle during database setup. This step is necessary since it's under the ORACLE_BASE directory and the path includes the database SID, which can't be known in advance. (Even though this is XE and the SID is fixed, it uses the same scripts—and if you know how, you can indeed change the SID of an XE/FREE database.)

Further confirmation is visible in the date/times on the directories created under ORACLE_BASE/admin/ORACLE_SID. The ORACLE_BASE/admin directory is part of the database image and its timestamp reflects the image build date:

bash-4.2# cd /opt/oracle
bash-4.2# ls -l
total 44
drwxr-x---. 1 oracle oinstall    16 Aug  2  2023 admin
drwxr-x---. 1 oracle oinstall    16 Aug  2  2023 audit
drwxr-x---. 1 oracle oinstall    31 Aug  2  2023 cfgtoollogs
-rwxr-xr--. 1 oracle oinstall  2571 Aug  1  2023 checkDBStatus.sh
-rwxr-xr--. 1 oracle oinstall  7046 Aug  2  2023 configTcps.sh
-rwxr-xr--. 1 oracle oinstall 10726 Aug  2  2023 createDB.sh
drwxr-x---. 1 oracle oinstall    88 Mar 10 17:39 dbs
drwxrwxr-x. 1 oracle oinstall    34 Aug  2  2023 diag
drwxr-x---. 1 oracle oinstall    28 Aug  2  2023 homes
drwxrwx---. 1 oracle oinstall     6 Mar 10 17:39 oraInventory
drwxr-xr-x. 4 oracle oinstall    51 Mar 10 17:39 oradata
drwxr-xr-x. 1 oracle oinstall    17 Aug  2  2023 product
-rwxr-xr--. 1 oracle oinstall 11350 Aug  1  2023 runOracle.sh
-rwxr-xr--. 1 oracle oinstall  1022 Aug  1  2023 runUserScripts.sh
drwxr-xr-x. 5 oracle oinstall    52 Aug  2  2023 scripts
-rwxr-xr--. 1 oracle oinstall  1156 Aug  1  2023 setPassword.sh

However, the XE subdirectory was (re)created after the container/database started. The timestamps match those in the DBCA log file:

bash-4.2# cd admin
bash-4.2# ls -l
total 0
drwxr-x---. 1 oracle oinstall 50 Mar 10 17:32 XE

As are its subdirectories:

bash-4.2# cd XE
bash-4.2# ls -l
total 12
drwxr-x---. 4 oracle oinstall 8192 Mar 10 17:39 adump
drwxr-xr-x. 2 oracle oinstall   20 Mar 10 17:37 dpdump
drwxr-x---. 2 oracle oinstall   36 Mar 10 17:37 pfile
drwxr-x---. 2 oracle oinstall   44 Mar 10 17:32 xdb_wallet

My original advice was to create a directory under the dpdump directory, but that won't work, either:

docker run -d --name ORCL21XE \
       -v /oradata/ORCL21XE/data:/opt/oracle/oradata                 \
       -v /oradata/ORCL21XE/startup:/opt/oracle/scripts/startup      \
       -v /oradata/ORCL21XE/setup:/opt/oracle/scripts/setup          \
       -v /oradata/ORCL21XE/dpdump:/opt/oracle/admin/XE/dpdump/test  \
       container-registry.oracle.com/database/express:21.3.0-xe
docker logs -f ORCL21XE

The directory remains, but container startup complains and its contents are purged:

45b3d3ee1f17c35259424065f3a0af44cd0857155e86a3193da28a075de8bfc7
rm: cannot remove '/opt/oracle/admin/XE/dpdump/test': Device or resource busy

bash-4.2# ls -l
total 0
drwxr-x---. 1 oracle oinstall 64 Mar 10 18:35 XE
bash-4.2# ls -l XE
total 12
drwxr-x---. 3 oracle oinstall 8192 Mar 10 18:39 adump
drwxr-x---. 1 oracle oinstall   32 Mar 10 18:39 dpdump
drwxr-x---. 2 oracle oinstall   22 Mar 10 18:35 pfile
drwxr-x---. 2 oracle oinstall   44 Mar 10 18:35 xdb_wallet
bash-4.2# ls -l XE/dpdump
total 4
-rw-r-----. 1 oracle oinstall 151 Mar 10 18:39 dp.log
drwxr-xr-x. 2 oracle oinstall   6 Mar 10 18:35 test
bash-4.2# ls -l XE/dpdump/test
total 0

My recommendation for working around this is:

• Mount your local dpdump directory to a path outside of ORACLE_BASE/admin/ORACLE_SID. For example, /dpdump.
  Then, use a script under the setup directory to manage things. Scripts in setup are called after database creation completes, and are only called the first time the container starts. The options include:
• Copying the files from /dpdump to /opt/oracle/admin/XE/dpdump.
• Creating a new database directory that points to /dpdump.
  I hope this helps explain the situation and provides a workable solution for you! And, thank you for teaching me something new about the Oracle Database!

[AlBundy33]

using another directory means that we have to create a directory in the db (create directory dpdump as '/dpdump')
my goal was to use the existing directory and after the startup the volume contains only a logfile - therefore deleting the directory at startup seems a little bit useless to me.
Doesn't this also mean that the directory is deleted everytime you've pulled a new image (haven't tested this yet)?

[oraclesean]

This directory is (re)created every time a new database instance is added since its path is only known after the SID is given to DBCA. If you don't want to create a custom directory (via SQL, create directory ...), you could add a script to your setup entrypoint that moves files into the directory from some location outside the mounted volume.

Re: "Is the directory deleted every time you pull a new image?" It depends.

• If you're creating a new database, yes. The call to DBCA invokes the code that empties the directory.
  However:
• Dropping an existing container that mounted oradata to a volume, then recreating it using the same SID and mount path but a new image means the database startup sees an existing database and skips the DBCA step.

You can use this to clone a database (say, for a dev/qa environment) as follows (commands simplified for clarity):

• Create a base container:

docker run -d --name GOLD \
       -e ORACLE_SID=XE   \
       -v /oradata/GOLD/data:/opt/oracle/oradata \
       container-registry.oracle.com/database/express:21.3.0-xe

• Let it start and create the database.
• Once you see the "Database is ready..." message in the logs, stop the container.
• The /oradata/GOLD directory is the entire database. Copy the contents to another directory (note the command used here copies the necessary hidden directories that the startup scripts look for to determine database existence):

cp -rp /oradata/GOLD/* /oradata/ORCL21XE/

• Create a new container:

docker run -d --name ORCL21XE \
       -e ORACLE_SID=XE       \
       -v /oradata/ORCL21XE/data:/opt/oracle/oradata           \
       -v /oradata/ORCL21XE/dpdump:/opt/oracle/admin/XE/dpdump \
       container-registry.oracle.com/database/express:21.3.0-xe

• This container starts, sees configurations and datafiles in the oradata directory and starts the database. DBCA doesn't run and the dpdump directory isn't overwritten.

For 21c Express Edition (or 23ai FREE Edition) the ORACLE_SID variable can't be used to change the SID because it's (semi-)fixed. For other editions, the SID of the "cloned" database (as well as other values that affect configuration, eg character set, etc) must match the original.