Linux LVM for Oracle Database on OCI

Oracle Database as a service (DBCS) on Oracle Cloud Infrastructure (OCI) had been traditionally built based on Oracle Grid Infrastructure with ASM as the main storage layer for the database, however Oracle recently has started to offer a Linux LVM as the storage alternative. Which option is the better alternative? Let’s review some of the differences between the two options.

When provisioning a new DBCS VM on the OCI you are given two choices, Oracle Grid Infrastructure and Linux LVM, Linux LV is positioned by Oracle as a better option for quick deployment.

Screen Shot 2019-11-17 at 9.01.43 AM.png

How much faster is the deployment of a VM with LVM in compared to the GI ASM option? I compared both options in the Toronto region. The creation of the LVM based database system took from 14:07 GMT to 14:25 GMT or just about 18 minutes. For the ASM based DBCS, the deployment took from 14:35 GMT to 15:56 GMT taking 1 hour 21 minutes. The ASM option was about 4.5 times slower.
What are the other differences? First, the LVM based DB system is only a single node option.RAC is not an option on LVM – only single node. Second, there are differences with the available database versions. The GI ASM option offers the full range from 11gr2 to 19c but the LVM based option can use only 18c and 19c database versions.

Screen Shot 2019-11-17 at 10.09.39 AM.png

Third, the initial storage size available on GI ASM version is from 256GB up to 40 TB where as for the LVM option the initial size is from 256 Gb to 8 TB. Scaling is different as well. The max storage scaling for the LVM option depends on the initial storage size chosen during creation. For example, for the initial 256 Gb, we can scale up only up to 2560 Gb. The full matrix on the scaling options for LVM based database can be found in the Oracle documentation.
On the LVM based VM, we are getting not one but two different volume groups for our database. One of them is 252 Gb RECO_GRP designed for redo logs and has been built based on two 128 Gb physical volumes and the second one is the DATA_GRP with another two 128 Gb volumes.
Screen Shot 2019-11-17 at 10.29.32 AM

On the ASM version, we have eight 64 Gb disks for two external redundancy ASM disk groups. It is relatively the same volume size and the same redundancy level. It looks like Oracle uses hardware raids vs ASM or LVM based protection.
Screen Shot 2019-11-17 at 11.11.12 AM.png

Screen Shot 2019-11-17 at 11.13.20 AM.png

Screen Shot 2019-11-17 at 11.17.22 AM.png

What about performance? I tried a simple load test using Dominic Giles’ Swingbench tool and compared similar runs on the LVM and on the ASM based DB system created in the same region using the same VM shape and storage size. I used a small VM.Standard2.1 shape for my VM and 256 Gb initial storage allocation.The options for the “oewizard” generator were “-async_off -scale 5 -hashpart -create -cl -v”.
Here are results for LVM based deployment.
The SOE schema creation time:

Screen Shot 2019-11-17 at 11.20.56 AM.png

For the test itself I used the “charbench” with parameters “-c ../configs/SOE_Server_Side_V2.xml -v users,tpm,tps,vresp -intermin 0 -intermax 0 -min 0 -max 0 -uc 128 -di SQ,WQ,WA -rt 00:10:00”

LVMforDBCS_12.png

Here is the test result summary for the LVM based instance:

LVMforDBCS_13.png

And here are results for the ASM GI installation.
The SOE schema generation:
Screen Shot 2019-11-17 at 12.29.03 PM.png

We can see that it took 58 min on ASM vs 34 min on LVM with 24,544 rows generated per second on ASM vs 43,491 on LVM. I cannot say for sure without more elaborate troubleshooting why it was so slow, but I could see that CPU usage was significantly higher on the ASM based VM than on the LVM and it seemed that not all the load was from the database. Some other tools (like Oswatcher) contributed to the load. Probably it could show different results with bigger shapes where it would be able to use more CPU.

And here is the test result summary for the ASM based instance:
LVMforDBCS_14.png

LVMforDBCS_15.png

The tests showed relatively the same performance ratio between LVM and ASM based instances as during the data generation. The LVM was about two times faster than the ASM based instance. When I looked at the AWR for the ASM based instance it seemed that the CPU was the main bottleneck in the performance. As I said earlier it is quite possible that for larger VMs with more CPU the difference would not be as big.

Overall, the LVM based option for DBCS can be a great option if you want to fire a new single-node Oracle DBCS instance and you can work within the scaling and DB version limitations. In terms of performance, the LVM had much better performance results as compared to the ASM option for a small 1 OCPU shape VM. In my opinion, LVM is as a good tool for developers and testers or even for production machines considering the superior performance results with a small machine.