I'm building an Oracle Database 19c image on Windows Server Core 2019 using Windows containers. The Docker build completes successfully and the image may work at first, but later rebuilds or changes in cache produce inconsistent results. Oracle directories such as diag, network, and bin become inaccessible with "Access is denied," folders appear locked, and sqlplus.exe sometimes seems to disappear. Rebuilding can temporarily make the image work again. The Dockerfile installs the Visual C++ runtime, extracts an Oracle 19.3 database home, runs an installation batch file, modifies sqlnet.ora, copies several application directories, and then runs a database-creation script. Has anyone encountered this behavior, and is Oracle on Windows containers a viable setup for a legacy Windows application?
1 Answer
Oracle Database running inside a Windows container can be extremely fragile, especially with an older 19c home and a Server Core base image. The symptoms sound more like Windows ACLs, file-layer behavior, or an installation/runtime process leaving files in an inconsistent state than Oracle intentionally locking its own directories. If possible, the more reliable arrangement is to run Oracle in a Linux container on a Linux host and keep the legacy Windows application separate. If Oracle must remain on Windows, inspect the effective permissions and ownership after every Dockerfile step, verify that the install script is not changing ACLs or deleting files, and test each COPY/RUN layer independently. Also confirm that the build context and Docker cache are not reusing a partially modified Oracle directory; rebuilding with cache disabled can help identify that.
The application is a large Windows legacy monolith, so moving the whole stack to Linux is not currently realistic. I’ll investigate the ACL changes and installation script separately, while checking whether the Oracle database can be hosted outside the application container.