In my last blog I was talking about the vblock and its relevance to oracle database.
Customers now realize that architecting, planning, testing, verifying, deploying, and maintaining interoperability between infrastructure components saps budgets and resources while adding no value to the business. This is the reason that the customers are moving towards converged architecture. Figure 1 illustrates the above logic.
Figure 1. Build vs Buying a Car/Converged Architecture
In this regard vBlock 540, XtremIO and Oracle database stand out to be the winner as per Gartner demonstrated in Figure 2.
Figure 2 : Magic Quadrant for Integrated Systems
As per Gartner , VCE is clearly the market leader with the following distinguishing features :-
So, to run this factory-integrated and validated reference architecture of VCE products (like vBlock) we need to follow some best practices so that we can extract the maximum benefits from the 3 softwares viz. vBlock , XtremIO and oracle database. So, I will try to document some of the best practices from Oracle database standpoint in this blog and in the next subsequent blog.
Firstly, The default block size for Oracle Redo Logs is 512 bytes. This default block size will cause redo log entries to be misaligned by the ready-modify-write modify operations (explained in the blog post by flashdba); redo log block size should therefore be set to 4 kB. In order to create redo logs with a 4 kB block size, and ASM disk groups with a 4096 byte sector size, add the option _disk_sector_size_override=TRUE to the parameter file of the database instance. Oracle’s default block size of 8k works well with XtremIO. This setting provides a great balance between IOPS and bandwidth, but can be improved upon in the right conditions. The new versions of Vblock 540 and XtremIO all flash array performance is 1.5X faster than the previous release as it has been optimized for 8k-block size. If the rows don’t fit nicely in 4k or above block sizes, it will be better to stick with the default setting. For data files, I/O requests will be in a multiple of the database block size – 4k, 8k, 16k, etc. If the starting addressable sector is aligned to a 4k boundary, optimal condition is met.
Secondly, Oracle controls the maximum number of blocks read in one I/O operation during a full scan using the DB_FILE_MULTIBLOCK_READ_COUNT parameter. This parameter is specified in blocks and defaults to a 1 MB read size. This value should be set to the maximum effective I/O block size divided by the database block size. If there are multiple tables with PARALLEL_DEGREE_POLICY set, reduce this to 64 kB or 128 kB. If you’re running with the default block size of 8 kB, this DB_FILE_MULTIBLOCK_READ_COUNT will need to be 8 or 16 respectively.
Thirdly, XDP protects the data while on disk, there is no need to use additional redundancy; Oracle should be configured to use ASM External redundancy, and also to use the default ASM stripe sizes. Best practice is to use four LUNs for the DATA disk group to allow the host to use simultaneous threads. The REDO and FRA disk groups should use two LUNs each. The traditional complexities of storage configuration have evolved to faster resulting into more simplified provisioning as all database data receives the sub-millisecond performance of all flash array and also the protection of XDP in XtremIO and vBlock 540. For Configuring Oracle Disk Groups, the following guidelines may be followed :-
Multiple LUNs should be configured – each has its own queue, and maximizing queue depths will be important in Oracle environments. This is a host requirement, and is not needed by the XtremIO array, where one LUN can easily service all the required IOPs. It is also not required to separate LUNs by I/O type, since XtremIO randomizes accesses internally. All LUNs should be created with the 512 byte sector type. LUNs accessed by a hypervisor cluster should use a consistent addressing scheme. If LUN numbers do not match, VM power up operations or migration operations may be affected. I am going to discuss some best practices of Oracle Database in the converged architecture segment in my next blog.