0

I am creating a Docker image for Oracle database, and many different containers will be generated from the same image.

When I start the Oracle instance, for some reason a few bytes are written to all active datafiles. Docker saves a diff from the container to the base image, and the diff is the whole file that changed, so each time I start a container more than 6 GB are written to disk just for starting the database.

So, why does Oracle write to the datafiles when starting the database? The most logic behavior would be writing to the datafiles only when data is changed and commited. Can I do something to change that?

Besides Oracle Linux (which is the base for my image) I have also tried that on Windows and the behavior is the same, all datafiles are written.

I tried setting the tablespaces to read-only. That avoids the write operation, however when I set the tablespace to read-write it immediately writes to the file, causing the problem again.

Just to be clear, I need the tablespaces to be writeable, but only when the data actually changes.

1 Answer 1

1

There is no way to avoid that. Beside users data Oracle also contains a lot of metadata - these have to be maintained too. Internally Oracle maintains a number called SCN (System Change Number). This number increases whenever "something" changes in the database.

This SCN number is written into the head of every datafile and also into every controlfile. When opening(starting) the database Oracle checks that this number is the same in all files. Then it assumes that files are consistent.

This SCN increments even if there is no load for the database. Also there background jobs like statistics gathering do some load. Also users might create system trigger ON DATABASE STARTUP which will execute some job when database starts.

Generally Oracle database servers are not good candidates for virtualization. The staff with journaling Oracle does internally too, so you keep the same data twice(these files are called Archive redo-logs). So if you drop the container diffs(for datafiles only), Oracle will be able to survive that, because it will be able to replay transactions from redo-logs.

PS: When cloning databases you should also consider changing database SID to be unique. Or least you should use nid to change database unique number DBID. Otherwise you can have troubles when restoring RMAN database backups.

1
  • Thanks for the explanation. I hoped there would be a way to prevent that, but it seems I will have to deal with the extra disk space needed. May 25, 2015 at 11:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .