Oracle Cloud: start/stop automatically the Autonomous Databases

In the previous post I've setup all the environment to be able to easily control the OCI services without bothering with the sign-in headers, and without installing anything. In this post I'll used the oci-curl() function to stop all my Autonomous Database services. In the previous post, I've set the environment variables for the private and public key, and the user, tenant and compartment OCIDs. I'm adding two variables to identify the endpoint I'll use (US-Ashburn-1 here) and the version of the REST API (20160918 here) which are both part of the URL.

Here are all my environment variables. If you set them to your values, you should be able to use the same commands as mine:


Here is how I use the OCI documentation sample to define the oci-curl() function in my current shell directly from the web documentation:

source <( \
 curl     \
  | grep -vE "(local tenancyId|local authUserId=|local keyFingerprint|local privateKeyPath=)" \
  | sed -e '1s/^.*#/#/' 

List the services

I can now list my Autonomous Databases, ADW and ATP, with:

for service in autonomousDatabases autonomousDataWarehouses
  oci-curl $endpoint get "/$apiVersion/$service?compartmentId=$compartmentId" | jq -r '.[] | [ .dbName , .lifecycleState , .id ]  | @tsv';

I've projected the name, state, and OCID with JQ and used @tsv formatting here to get tabs between the columns for a nice formatting. The result is:

ATP     AVAILABLE       ocid1.autonomousdatabase.oc1.iad.abuwcljtthygmwsbbsr2e3ve5kwrtvyevpbr6sgmrocepqa6wtr2yx73xtoq
ADWC    AVAILABLE       ocid1.autonomousdwdatabase.oc1.iad.abuwcljrbwuhg2iyzshauzvsjuxuqnd7wcg35xezlmxmtoitqhpw3hfqij3a

You need to remember that /autonomousdwdatabase is for the ADW service and the /autonomousdatabase for ATP. You know that, with Oracle products, the commercial names are often decided after the implementation, and then the API names may not match the common name. But don't worry, all this is documented:

Stop the services

The state "AVAILABLE" means that the service is started (which is the OPEN state for the PDB, as those services are PDBaaS). We can filter on them with JQ select(.lifecycleState=="AVAILABLE") and then call the "stop" API with a POST request:

for service in autonomousDatabases autonomousDataWarehouses
 for id in $( 
  oci-curl $endpoint get "/$apiVersion/$service?compartmentId=$compartmentId" \
  | jq -r '.[] | select(.lifecycleState=="AVAILABLE")|.id' 
 ) ; do
  oci-curl $endpoint post /dev/stdin "/$apiVersion/$service/$id/actions/stop" <<<"{}" | jq -r '.dbName + ": " + .lifecycleState' 

This gets the OCID (.id) for all services that are in the AVAILABLE state and calls the /$id/actions/stop method for each of them. The POST method requires a file and I just pass an empty JSON here, mentioning /dev/stdin and sending "{}" through a here string in bash. The stop query returns the service information and I use JQ to display the name and the status:



After a few seconds, running the command above to list services and status with tabs, I can see that they are in the STOPPED state:

ATP     STOPPED ocid1.autonomousdatabase.oc1.iad.abuwcljtthygmwsbbsr2e3ve5kwrtvyevpbr6sgmrocepqa6wtr2yx73xtoq
ADWC    STOPPED ocid1.autonomousdwdatabase.oc1.iad.abuwcljrbwuhg2iyzshauzvsjuxuqnd7wcg35xezlmxmtoitqhpw3hfqij3a

Start the services

In order to start the database, the call is simply /$service/$id/actions/start instead of /$service/$id/actions/stop

for service in autonomousDatabases autonomousDataWarehouses
 for id in $( 
  oci-curl $endpoint get "/$apiVersion/$service?compartmentId=$compartmentId" \
  | jq -r '.[] | select(.lifecycleState=="STOPPED")|.id' 
 ) ; do
  oci-curl $endpoint post /dev/stdin "/$apiVersion/$service/$id/actions/start" <<<"{}" <<<"{}" | jq -r '.dbName + ": " + .lifecycleState'

So what?

This oci-curl() function is a very simple way to manage your autonomous database services, without having to install any tool. You just need the private key and a few environment variables. Looking at the script is also a good way to understand how to build the POST/GET request headers as expected by the Oracle Cloud REST API. Of course, for production, the OCI client or OCI SDK will be preferred.

Add new comment

You are here