oracle database image size is huge

[nnar1o]

I created a database image using your scripts:
REPOSITORY TAG IMAGE ID CREATED SIZE
oracle/database 12.2.0.1-ee 8adc010e6d91 13 minutes ago 13.2GB

when I check size of files using bash in container: 5.9G

Is it possible to shrink the size of image? I.e. you can merge RUN commands in your script and remove files immediately after install to avoid producing to many layers.

[gvenzl]

Yes, you can use the --squash option to produce a smaller image, see: https://geraldonit.com/2017/11/13/how-to-create-small-docker-images/

If you look at the Dockerfile you will see that the RUN commands are pretty much already all merged.
The issue is simply with copying in a ZIP file and unzipping it.
Even unzipping and deleting the zip file within a single RUN instruction doesn't avoid the extra space being wasted, unfortunately.

[avindra]

@gvenzl Thanks, the --squash option provides a much leaner image:

$ docker images
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
oracle/db-prebuilt   12.1.0.2-ee         801cde12e07c        6 minutes ago       9.5GB
oracle/database      12.1.0.2-ee         aad4e86f3d3b        23 minutes ago      5.05GB

However, as you can see the prebuilt image per the docs doesn't stay lean.

Do you have any recommendations for cutting down the size of the prebuilt image? I'm testing docker-squash as I'm writing this...

[avindra]

Update on squashing. the library I linked doesn't work, so I ended up using this instead:

https://github.com/goldmann/docker-squash

result;

$ docker images
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
oracle/db-prebuilt   12-squashed         8029648214f6        15 minutes ago      9.01GB
oracle/db-prebuilt   12.1.0.2-ee         801cde12e07c        About an hour ago   9.5GB

So it saves a decent 1/2 GB, but 9GB still seems pretty chunky for a totally empty database...

[gvenzl]

The image gets bigger because you have data files in the image now, which come with default sizes. If you want to have a smaller image but still with a pre-built database there is a great blog post on the Mobiliar Database Blog which shows you a couple of tricks to make some data files and tablespaces even smaller.

Their case was for 11g XE but the steps for reducing SYSAUX, UNDO and so forth remain the same also for 12c.

[MaxCCC]

The runOracle.sh scripts is a lot different for xe-11 than 12 which makes this nice blog not that useful :/

[gvenzl]

The procedure to remove components from the database remains the same.

[lvthillo]

@avindra The --squash option seems to work pretty good for me. I've just enabled the experimental docker daemon to use it:

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
oracle/database     12.2.0.1-se2        213f7feb796b        53 seconds ago      6.25GB
<none>              <none>              da45af7947ce        2 minutes ago       13.2GB

[gvenzl]

Just note that @avindra image is bigger because he keeps a pre-built database inside the image as well (data files, etc). So he won't quite get to the 6GB :)

[gvenzl]

We have now also implemented multi-stage builds by default which makes using the --squash option redundant. I'll close the issue for now as I believe this to be answered. Please reopen if there are outstanding questions.

[deusaquilus]

The image gets bigger because you have data files in the image now, which come with default sizes. If you want to have a smaller image but still with a pre-built database there is a great blog post on the Mobiliar Database Blog which shows you a couple of tricks to make some data files and tablespaces even smaller.

Hi @gvenzl. Thanks for the link!

I'm actually trying to go through the instructions that Alain posted using 18c XE... with mixed success. I can't decrease the size of system01.dbf via alter database datafile because it claims that 357M has already been exceeded. Do you know if there is a way to overcome this?

Also, I can't re-create sysaux via his instructions because since in 18c the tables are no longer WRI$_OPTSTAT_... so I don't know which ones to move. Is it a simple matter of finding out which tables end with "HISTORY" and then what all of their indexes are?

[salob]

I know this is old but I had this problem also and went with this approach which I describe here:

https://www.linkedin.com/posts/sian-o-briain-194a008a_docker-have-you-ever-had-this-problem-activity-6753399399659008000-s_PA

But basically you get rid of the copy instructions by serving up the installers/patches via a local http server (you can do this with one command via python)

That way you can download,extract and delete all in the one RUN instruction.

Hope it helps