(Photo by Joël Assuied, on Unsplash)
I just started working on Exadata Cloud at Customer. And with this, come my first mistakes 😉
One of my compute node had all cloud tooling scripts located in the adequate directories :
# ls -l /var/opt/oracle/exapatch/
-r-xr-xr-x 1 oracle oinstall 0 Feb 4 21:23 exadbcpatchsm
-r-xr-xr-x 1 oracle oinstall 0 Feb 4 21:23 exadbcpatchmulti
-r-xr-xr-x 1 oracle oinstall 0 Feb 4 21:23 exadbcpatch
but for an obscure reason (made of failed update combined with full filesystem), they were all emtpy.
(Photo by Alex Guillaume, on Unsplash)
I recently encountered a problem, for which I do not have any clue yet. But at least, I have a workaround. The goal of this blog post is to remember the exploration towards this workaround. And then to switch back to a normal sitution when possible.
For some reason, 120 development databases were configured to use Shared Server Architecture. The day after this change of configuration, a lot of users started complaining about a fully-automatized-0-problem-encountered-in-the-last-2-years-procedure to duplicate a production database to development database … Indeed, this procedure begins with stopping target database, and this day, failed almost everytime during this step … Why ?