DB Segment I/O Script (Doc ID 2533111.1)

Last updated on SEPTEMBER 29, 2021

Applies to:

Goal

Write-back Flash Cache (WBFC) is recommended, but you need to understand the potential impact before switching it (either direction), especially on older systems with a smaller Flash Cache.  Look at the read/write ratio of the system, combined with the size of the working set of data on that system.  If you have a system with HIGH read/write ratio (high percentage of read activity), and if the corresponding working-set is large in comparison to the FlashCache size, enabling WBFC could potentially have a negative impact on performance.

X5 machines came either with 4TB drives or 8TB drives.  Customers can choose either NORMAL redundancy or HIGH redundancy, and an allocation model of 80/20 or 40/60 (or custom).  X5 used 1.6TB Flash cards, with 4 per storage cell, or 6.4TB per cell total.  Look at the relationship of FlashCache size to DATA_DG size, combined with the read/write ratio and working set size.

For example, DATA_DG with HIGH redundancy on 4TB drives with 80/20 allocation model is roughly 12.8TB (per cell).  The FlashCache therefore is 50% the size of DATA_DG.  The typical read/write ratio is 0.8 (80% read), so you have 20% writes.  If the disks are completely FULL, you have 12.8TB of data per cell.  As an example, the database might contain around 25% “active” data, so the working set would be approximately 3.2TB.  If 80% of that 3.2TB is being read, then 20% is being written.  In that case, you would need 3*3.2*.2=1.92TB of space for writes, and 2.56TB for reads.  1.92+2.56=4.48, is less than the 6.4TB of available space in the FlashCache, so no problem.

Of course if the customer has 8TB drives and/or is using NORMAL redundancy, the situation is quite different.

Use the “DB Segment I/O Script” (available on the sizing tool) to calculate the read/write ratio and working set size of any database.
 

Solution