End to End (E2E) 4kn support with VMware vSphere 9.0 – What does that mean for Oracle Workloads

VMware finally released End to End (E2E) 4kn support for VM vmdk’s with the VMware vSphere 9.0 release , announced June 19, 2025.

Business Critical Oracle databases would extremely benefit from using 4k redo blocksize to drive IO intensive workloads as opposed to using 512byte redo blocksize for all the obvious reasons , yes , it comes at the cost of redo wastage but there are pros and cons to everything.

The previous blog Oracle Workloads and Redo Log Blocksize – 512 bytes or 4k blocksize for redo log addressed the advantages of using Oracle Redo Log with 4k blocksize (default is 512 bytes with blocksize choices  512bytes, 1k and 4k) on VMware platforms and current challenges associated with that with roadmap guidance. The testing was done using 512e RDM’s to prove the theory.

This blog attempts to demonstrates the advantages of using Oracle Redo Log with 4k blocksize on vmdk’s using VMware vSphere 9.0 platform.

VMware vSphere 9.0 End to End (E2E) 4kn support 

In VMware vSphere 9.0, the 4Kn E2E feature introduces support for:

• Front end – 4K VMDKs presented to VMs
• Back end – 4Kn NVMe SSDs for vSAN ESA. OSA will not support 4Kn SSDs.
• ESXi will also support 4Kn SCSI SSDs for local VMFS and external storage.

More details can be found at vSphere and VMware Cloud Foundation 9.0 Core Storage – What’s New

FAQ: Support statement for 512e and 4K Native drives for VMware vSphere and vSAN

• This article applies to Direct attached HDD drives.
• This article does not apply to external storage arrays as long as LUNs presented to ESXi initiators use 512 logical sector size (READ_CAPACITY should report 512 logical block).
• 512e SSDs/NVMe drives are supported with all supported ESXi releases as long as the controller supporting these SSD/NVMe drives is listed on vSphere VCG. For vSAN environments the controller has to be listed on the vSphere VCG for vSAN. Please check with your vendor if their listed controller supports SSD/NVMe drives.

More details can be found at FAQ: Support statement for 512e and 4K Native drives for VMware vSphere and vSAN

ESXi 4k Format

ESX supports the 4Kn sector technology. In the 4Kn devices, both physical and logical sectors are 4096 bytes (4 KiB) in length. The device does not have an emulation layer, but exposes its 4Kn physical sector size directly to

ESX detects and registers the 4Kn devices.

Starting with vSphere 9.0, VMs can understands the backend device as 4Kn and send a 4K I/O through the 4Kn virtual disk to the device.

When you use 4Kn devices, the following considerations apply:

• ESX supports 4Kn local devices for use with VMFS and vSAN datastores.
• ESX can boot only from a 4Kn device with UEFI.
• You can use the 4Kn device to configure a coredump partition and coredump file.
• Only VMs with hardware version 9.0 and later can support 4Kn virtual disk.
• Once the VM disk is created, the sector size of the disk cannot be changed.

More details can be found at Sector Formats for Storage Devices

Test Bed

The Test bed was an ESXI 9.0 environment as shown below.

VM ‘Oracle21c-OL8-vNVME-4kn’ was created with 32 vCPU’s, 224GB memory with storage on All-Flash Pure array with Oracle SGA & PGA set to 68G and 10G respectively.

A single instance database ‘ORA21C’ with multi-tenant option was provisioned with Oracle Grid Infrastructure (ASM) and Database version 21.0 on O/S OEL 8.3.

Oracle ASM was the storage platform with Linux udev for device persistence. ASMLIB and ASMFD also be used instead.

The vmdk’s for the VM ‘Oracle21c-OL8-vNVME-4kn’ are on a Pure Storage FC datastore.

In case of VM ‘Oracle21c-OL8-vNVME-4kn’ , we created a 100GB vmdk with sector size set to 4kn using vmkfstools.

The command to create a 100G vmdk with 4k sector size is shown as below  –

vmkfstools -c 100G -d zeroedthick –sectorSize 4kn test.vmdk

The above command creates a 100G LZT vmdk named “test.vmdk” with sector size as 4k (4kn vmdk).

Rest of the VM vmdk’s are the same as in the earlier case.

Test Case

SLOB 2.5.4.0 was chosen as the load generator for this exercise with following SLOB parameters set as below:

UPDATE_PCT=100
SCALE=25G
WORK_UNIT=3
SCHEMAS=80
REDO_STRESS=HEAVY

We set the ThreadsperSchema to 100

We deliberately chose the minimum Work Unit size to drive the most amount of IO with heavy stress on redo to study the performance metrics differences between using 512bytes and 4k redo block sizes.

Test Results

Remember, any performance data is a result of the combination of hardware configuration, software configuration, test methodology, test tool, and workload profile used in the testing , so the performance improvement I got with my workload in my lab is in no way representative of any real production workload which means the performance improvements for real world workloads will be better.

The first test was conducted with redo block size of 512bytes.

The second test with redo block size of 4k.

The ASM disk group housing the redo logs has their sector size set accordingly.

We can see, by using redo logs with 4k blocksize as compared to 512bytes

• Redo size (bytes) have increased from 1,058,071,751.7 (512 bytes blocksize) to 1,307,781,672.0 (4k blocksize) – Increase of 23.6%
• Executes (SQL) / Transactions have increased by 23.5% / 23.6% respectively from 512 bytes blocksize to 4k blocksize

From a wait event perspective: –

Wait event ‘log file switch completion’ indicates that a session is waiting for a log file switch to complete. This event typically arises when the current online redo log file is full and a switch to the next log file is initiated, but the switch cannot complete immediately, indicative of heavy workload, which is a good problem to solve, you want to be able to push as much IO to the database as possible.

From a redo log performance perspective:

From a physical read/write perspective:

Summary

In summary, comparing the redo log 4k blocksize v/s 512b blocksize, we can see

• Redo size (bytes) have increased from 1,058,071,751.7 (512 bytes blocksize) to 1,307,781,672.0 (4k blocksize) – Increase of 23.6%
• Executes (SQL) / Transactions have increased by 23.5% / 23.6% respectively from 512 bytes blocksize to 4k blocksize
• Wait event ‘log file switch completion’ increase indicative of heavy workload, which is a good problem to solve, you want to be able to push as much IO to the database as possible
• More redo blocks generated for 512b blocksize, redo wastage with 4k redo block as expected, less time to write redo with large 4k blocksize and more redo to write with small 512b blocksize
• Increase in Total physical writes IOPS with 4k redo blocksize

Thus, you must evaluate the trade-off between performance and disk wastage when planning the redo log block size on 4K sector size emulation-mode disks.

Summary

• This blog is meant to raise awareness of the advantages of using 4k redo block size v/s 512b with pros and cons
• This blog contains results that I got in my lab running a load generator SLOB against my workload, which will be way different than any real-world customer workload, your mileage may vary
• Remember, any performance data is a result of the combination of hardware configuration, software configuration, test methodology, test tool, and workload profile used in the testing

All Oracle on vSphere white papers including Oracle licensing on vSphere/vSAN, Oracle best practices, RAC deployment guides, workload characterization guide can be found in the url below

Oracle on VMware Collateral – One Stop Shop
https://blogs.vmware.com/apps/2017/01/oracle-vmware-collateral-one-stop-shop.html