Category: DBaaS

12 Days of #Cloud: Day 10

In a previous post, I talked about enabling backups on a #DBaaS instance where backups were disabled when the instance was created. Today I show you how to create a database with Cloud Backup enabled at the time of creating the instance. To store backups on the Oracle Cloud, we need to first create a storage container.

From the dashboard, choose Storage Cloud Service. And note down the REST Endpoint URL.

The page also shows the data center. Mine is us2. Go to the Storage Console to create a new storage container to store the backups. The storage console URL is https://storageconsole.us2.oraclecloud.com where you need to substitute the correct data center instead of us2. Thanks to Gokhan for the help.

Login prompt appears:

Input the Storage Cloud REST Endpoint URL and your Cloud account username/password to get to the Storage Console. Choose “Create Container”

For regular backups and file storage needs, choose Standard. For archive backups, choose Archive. Archive Storage Service is ideally suited for infrequently accessed large-scale data sets.

I created two containers. When using these containers for backup or for storage, Oracle DBaaS expects a URL that includes the domain name and container name. The format of  the URL is https://<identity-domain>.storage.oraclecloud.com/v1/Storage-<identity-domain>/<backup-container>

If the backup container is in the same identify domain as your database, then the URL may be shortened to Storage-<identity-domain>/<backup-container> Thanks to Scott Spendolini for this info.

Now, to Cloud Database console to create an instance. Everything is pretty similar to the first Instance I created, except for the backup configuration.

Backup destination is “Both Cloud Storage and Local Storage”. The Cloud Storage Container is the REST URL for my Storage Cloud + Container Name. If you check on the “Create Cloud Storage Container”, you can specify the name of a non-existing storage container. I provided the name of an existing container (Backup001) and my domain name is usatomtrial. The Complete URL is https://usatomtrial.storage.oraclecloud.com/v1/Storage-usatomtrial/Backup001.

After about a day of running database, I can see using RMAN that the backups are happening successfully.

Here are the default RMAN configurations.

Notice
CONFIGURE CHANNEL DEVICE TYPE ‘SBT_TAPE’ MAXPIECESIZE 2 G PARMS ‘SBT_LIBRARY=libopc.so, ENV=(OPC_PFILE=/u01/ app/oracle/product/12.2.0/dbhome_1/dbs/opcDBBKCL1.ora)’;
The backups are scheduled through root cron. Database backup is scheduled once a day, and archive log backups are done every 30 minutes. You may adjust the frequency if needed.

Though backups are scheduled, an on-demand backup can be performed from the Database Cloud Console.

You may also initiate a recovery from the Database Cloud Console.

The options are to recover using the latest backup (full + archivelog backups available), or specified datetime, or specified SCN.

Click Recover, and hopefully, you will have a recovered database without DBA intervention.

 

12 Days of #Cloud: Day 9

I have a 12.1. Database Cloud Instance, which comes with several patches including July 2016 PSU.

The dbaascli cloud tool can be used to query and apply patches. Before we use dbaascli, let’s check what the Cloud interface shows.

Choose the DBaaS instance and view details. The “Administration” tile shows one patch available. Shows the October 2016 PSU is available to apply. I guess PSU is the only patch Oracle strongly recommends everyone to apply.

The patch menu has two options – “Precheck” and “Patch”.

The precheck failed, not sure why.

Per documentation, updated the psunum= value with 12.1.0.2.161018 and executed the prereq check using dbaascli (command line on Linux VM), in the hope to get more information.

My troubleshooting did not go far, contacted cloud forum for help.

Based on the forum recommendation, updated the DBaaS tools to latest version to fix the issue.

To find out the current version and if there are any newer versions available, run “dbaascli dbpatchm –run -list_tools” command as root user.

The output does not show much information, but the log file does.

The version that came with DBaaS needs update.

[root@CLDB121 opc]# rpm -qa|grep -i dbaastools

dbaastools-1.0-1+16.4.5.0.0_161107.1102.x86_64

The latest version is 16.4.5.1_161213.1526.

Updating the tools was easy (BTW, I strongly suggest and expect Oracle to keep the cloud tools updated on my VM as I am subscribing to DBaaS service. It is not really my responsibility to manually update the cloud tools).

Once the dbaascli tool was updated to latest version, the precheck completed successfully.

Tried the same from front-end GUI also.

Applying the patch is a click of a menu item.

When the patch process begins, the database service is placed in maintenance status.

The log files are written to /var/opt/oracle/log/dbpatchm directory. You can monitor the patch progress through the log file (there is no progress indication, or log file access or error reporting detail through the GUI).

The log file shows details such as downloading the patch, unzip, stop services, apply patch, start services, run utlrp, etc.

The DBaaS service was down to apply the PSU patch for about 40 minutes, which is really good assuming no interference from DBA to apply the patch. I wish there was an option to schedule the patch through the cloud front-end management console.

Running the $ORACLE_HOME/OPatch/opatch lsinventory shows the patch apply status.

PSU can be applied using the dbaascli dbpatchm command or using the Cloud Interface. For all other one-off patches, use opatch.