Problems with Restart
You might experience unexpected side-effects after restarting an Oracle SOA Cloud Service instance or individual VMs. These effects can also occur after patching, which restarts VMs.
Restart fails after a scale down operation intended to remedy a quota breach
You can scale down a Oracle Database Classic Cloud Service database deployment or Oracle SOA Cloud Service instance if you have a quota breach in your account. Scaling down reduces compute resources. However, the automatic restart action can fail after scale-down.
For example, you could scale down a node from shape oc5 to oc3. Oracle SOA Cloud Service puts the service instance into Maintenance mode, changes the state of the node to Configuring, and stops any servers running on the node. After applying the changes, Oracle SOA Cloud Service is supposed to start the servers automatically. If the quota breach is not cleared by the time the orchestration is restarted with the smaller shape, the automatic server restart action could fail.
If the restart action fails, wait one hour for the quota breach to clear, then restart the service instance by using the Oracle SOA Cloud Service Console.
Monitor a VM’s boot log
You can monitor the boot progress of individual VMs by using Oracle Cloud Infrastructure Compute Classic. See Viewing the Boot Log of an Instance in Oracle Cloud Infrastructure Compute Classic. Ignore information in this topic about the Compute API.
My custom storage volumes have become detached
Custom storage volumes you have added after creating an Oracle SOA Cloud Service instance will become detached after restart operations.
Do not attach custom storage volumes to a service instance’s VMs. Any custom storage volumes are detached if the service instance is restarted.
If a service instance requires additional storage, add storage by scaling the service instance’s nodes as explained in Scaling an Oracle SOA Cloud Service Node.
My content changes on the Boot/OS volume are gone