Abstract
As I began looking for information on running Oracle in containers back in 2014, the consensus among Oracle experts wasn't very promising. Most database administrators dismissed Docker as the latest technology-de-jour among developers and not something capable of handling the demands of a database. They cited dire warnings about instability, poor performance, and data loss. Peers shared horror stories of various disasters rooted in the immaturity or fragility of Docker.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
I’m guilty of this attitude myself. Not only am I old enough to remember the joys of manually managing undo segments, I was among those who claimed they were too complicated and important to trust to one of Larry’s algorithms. I even gave a conference presentation where I advised against the feature. I can’t imagine how much time I wasted through my stubborn refusal to accept the newer, better way of doing things!
- 2.
The /var/lib/docker directory on a Linux host typically exists on the host boot volume. It can be relocated to a dedicated partition
- 3.
But what about patching and upgrades? Rather than patching a container, it’s better to build a new image for the patched version. The time and effort of patching is spent just once—during image build—and every container started from that image benefits. In a container environment, the patching process consists of stop** and removing the container running the old database version, then starting a new container using a patched image and pointing it at the data on a mount.
- 4.
Windows systems running Windows Subsystem for Linux version 2 are a special case. Where the container and volume are created—in the native, Windows OS, or in the Linux subsystem—affects their visibility. More on this later in the chapter!
- 5.
Volumes created “on the fly” when calling docker run are called anonymous volumes. They’re assigned uniquely generated names, making them more difficult to associate with specific containers. For clarity, the examples in this book use named volumes.
- 6.
Good news! Docker returns an error if you attempt to remove a volume that’s used by any containers—whether or not they’re running. The same isn’t true of manually managed directories!
- 7.
There are two types of secrets: runtime and build. Build secrets are available in Docker via Buildah.
- 8.
Images and build artifacts can grow to fill disk, too. See the section on space management toward the end of this chapter.
- 9.
The mount point is still in /var/lib/docker—it’s Docker’s internal reference telling the container where to find the volume.
- 10.
The --mount flag allows added capabilities for some special cases.
- 11.
Linux users (including those running Windows Subsystem for Linux, or WSL) may discover issues with directory ownership. See the section “Which Type of Volume Is Best” at the end of this chapter for more details.
- 12.
- 13.
Volumes don’t have to be attached to a host resource. If a map** isn’t given, Docker puts the files in the container’s private layer, as part of the union filesystem. In my experience, creating an Oracle database container without a volume for /opt/oracle/oradata is a bad idea—database creation is orders of magnitude slower!
- 14.
The /docker/entrypoint-initdb.d directory is used by multiple database vendors as an entrypoint for custom scripts.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2023 The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature
About this chapter
Cite this chapter
Scott, S. (2023). Persistence. In: Oracle on Docker. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-9033-0_7
Download citation
DOI: https://doi.org/10.1007/978-1-4842-9033-0_7
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-9032-3
Online ISBN: 978-1-4842-9033-0
eBook Packages: Professional and Applied ComputingProfessional and Applied Computing (R0)Apress Access Books