Monthly Archive: September 2015

Lost Disk after DBaaS Restart via Cloud Service Console

I have created a DBaaS instance three weeks ago, and now it was time to attach new storage in the Oracle Compute Cloud Service  to have additional disk space for some Trivadis tools. But after a reboot with a mouse-click in the DBaaS Cloud Service Console, the disk was lost and had to be re-attached.

The procedure to add additional storage is documented in this Oracle tutorial: http://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/dbaas/OU/IntroDBaaS/AddStorageDBaaSInstance/AddStorageDBaaSInstance.html

Creating additional  Storage in the Oracle Compute Cloud Service

In the Create Storage Volume menu, I have created a new storage volume of 10GB and attached it to my running DBaaS instance called TrivadisExPerf.

attach01

OS Verfication

After some minutes waiting, I logged in on the database server to verify the operation. The disk was attached as device xvdg.

Creating a Filesystem

Then I created a new partition with fdisk, formatted the partion as Ext4 and mounted it as /u05. At this point, I did not add something to /etc/fstab. But this had no impact for later actions.

Restart via DBaaS Cloud Service Console

The DBaaS restart was executed by the Service Console. In the background the DBaaS service was restarted automatically. The process is visible in the console and you can see the progress. I don’t know why Oracle requires more than 10 minutes for a simple restart, in some cases more than 20 minutes…

attach02

The Storage is lost…

After the restart I logged in again in the terminal. And what do I see? The storage was no more attached at the instance. There was no /dev/xdg or /dev/xdg1 visible.

After re-attaching the storage to the instance in the Oracle Compute Cloud Storage menu, the storage was back again. And I tried another way to restart a server…

attach03

Restart in the Terminal

First I checked again if the storage was attached. The device /dev/xdg was here.

Then I restarted the server with the shutdown command.

And after the restart, the storage was still here. The device /dev/xdg was available. And it didn’t require 10 mins, after 2 mins the server was back again and ready to log-in.

Summary

If you want to attach additional storage via Oracle Compute Cloud Service, it’s better at the moment NOT to restart your DBasS service instance via the console. Just use the good old shutdown command. I am sure, this can not be a feature, this is must be a bug.

Additional Information

When you attach a disk with the Scale Up function, then it works properly.

attach03

Now you have two ways how to attach additonal storage which are working. It’s like in the movie Indiana Jones and the Last Crusade:

You must choose. But choose wisely…

Patching a DBaaS Database in the Oracle Cloud

To apply a Patch on a Database which is hosted by Oracle is done with one mouse click. This service is available only if you have selected the full database service during the DBaaS order process.

To the manual: https://docs.oracle.com/cloud/latest/dbcs_dbaas/CSDBI/GUID-50BDEF7D-A30E-4B32-BAE7-486538413E2D.htm#CSDBI3422

Patchset Availability

As soon as a new Oracle patchset is available, you can see that in the database management dashboard of the selected database. The precheck function verifies if the selected database is ready to patch.

patch01

Precheck Result

After 2 until 3 minutes and a refresh of the page you see the result.

patch02

 

 

 

 

 

 

 

Command Line Interface dbpatchm

If you have no web access, all these steps can be executed manually in the shell. Therefore a command line tool called dbpatchm is available. You have to login as user root before using this tool.

List of available commands:

To the dbpatchm Documentation: https://docs.oracle.com/cloud/latest/dbcs_dbaas/CSDBI/GUID-50BDEF7D-A30E-4B32-BAE7-486538413E2D.htm#CSDBI3422

Patch Apply

If the prerequisite check is successful, we can apply the patch by selecting Patch.

patch03

If there are any Java Cloud Services (Weblogic Servers) which are using the selected database too, you can force to apply the patchset.

patch04

The patch progress is show in the dashboard.

patch05

In the background, Oracle transfers a new Oracle image where the selected PSU is already applied, extract it and changes the /u01/app location afterwards. During the patch apply process, the image is located under /u01/donwload:

Patch installed

After 45 minutes, the database is patched and up and running again.

patch07

The verification with OPatch shows the correct patch numbers. Here is an extract from the OPatch output. You can see that the apply-date is the 14th of July and that Oracle has installed bundle patch with patches for the RDBMS and the OJVM. I remember, in the background Oracle extracts a fully patched ORACLE_BASE / ORACLE_HOME directory for later usage.

The data dictionary is up to date too – the query on dba_registry_patch shows the correct PSU number:

Patching kills the EM12c Agent

Oracle is creating a new directory for the software, the old stuff which was in directory /u01/app is copied in /u01/app.ORG. So the EM12c Agent is not available anymore.

patch06

You have two possibilities to get the EM12c agent back:

  • Copy the installation directories from /u01/app.ORG back into /u01/app and re-attach the Agent Home in the inventory
  • Clean up the agent in EM12c and execute a reinstall

To avoid future problems, you can attach a new disk and use them for the agent or for other tools.

Summary

Patching a DBaaS database in the Oracle Cloud is very easy. All important steps are done automatically. In the background Oracle creates a new ORACLE_BASE directory in /u01. But you have to take care about installing your own tools or for example an EM12c agent. Also the database logs are no more available in the base directory. But you can find the in an subfolder of the direcory /u01/app.ORG where the old stuff is located.