Google BMS toolkit Observations

So despite all the warnings about certification and supportability you find you have to run an oracle database in Google cloud there is an option. you can use a colocated Bare metal server . It will be installed for you by google partners (ATOS) and will have a supported operating system preinstalled. For example Oracle Linux or Redhat Linux. After this the fun begins as you download the BMS toolkit https://github.com/google/bms-toolkit from github and puzzle through the Various options .

Oracle allows us to install the latest version of grid software but use an earlier version of the database. unfortunately the bms toolkit does not support such a configuration. you have to install the grid and database of the same version.

There are a few discrepancies between the checking script that verifies the downloaded software and the actual installation script...

Unfortunately the help is not very elaborate and does not explain this clearly.

For example the install-oracle.sh script allows us to store the oracle software in a google cloud storage bucket, or using the GCS fuse adapter option or in an nfs share and can install from any of the three locations.

There is a check-swlib.sh that is used to validate the media but it only supports a GCS bucket. this is not mentioned anywhere... hopefully the checking script can be enhanced in future.

The next issue is that there are specific version of patches that are recognized by the install script. The help says it is supposed to support up to 19.11 patchset. Surprisingly in one of the ansible scripts patchsets above 19.9 are commented out. as of today 19.9 patchset is not generally available it is password protected in MOS. hence the script is useless to install unless you are willing to search the source for the gi_patches array and uncomment the 19.11 entry.

Hint it's in \bms-toolkit-master\roles\common\defaults\main.yaml

Who da thunk ?

The next issue we faced when trying to setup the asm disks is that the script expects the disks to be pre partitioned but the json files expect to hold the disk paths but in oracle linux the device for the partitions appends a p1 to the block device path , but the script only appends a 1 to the block device. hence in oracle linux the script fails to locate the partitions. we tried to jury rig a fix by appending a p to the block device names. this allowed it to create the asm disks but we immediately faced another issue because the script went in and changed the owner of 317 files in our /dev folder to grid:asmadmin and removed rw permissions from other for all the 317 such files.

At this point we decided to forego use of the script and to do a simple oracle home clone using clone.pl from our source and eschew the use of asm in favour of striped lvm.

I would suggest to others if you want something simple setup and do not need RAC then it is better to steer clear of this buggy toolkit and go with a simple headless install.