Exadata Cloud at Customer : Reinstall Cloud Tooling

joel-assuied-179972-unsplash

(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.

Continue reading “Exadata Cloud at Customer : Reinstall Cloud Tooling”

Advertisements

Fun with attribute STOP_TIMEOUT for a custom clusterware resource

alex-guillaume-769172-unsplash

(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 ?

Continue reading “Fun with attribute STOP_TIMEOUT for a custom clusterware resource”