Oracle OLTP database tend to be mission-critical and usually have stringent IO latency requirements. Traditionally, these OLTP databases are deployed on a huge number of rotating Fibre Channel (FC) spindles to meet the low IO latency requirement while the effective capacity utilization of these spindles is very low, and thereby increasing the Total Cost of Ownership (TCO) of the solution.
EMC FAST VP and FAST Cache technology with Enterprise Flash Drives (EFDs), also known as solid-state drives (SSDs), are well suited to helping meet performance and response time requirements of mission-critical applications, as EFD drives can provide higher IOPS (3000-3500) and extremely low-latency than traditional FC drives (180 – 200 IOPS).
FAST VP and FAST Cache can be used alone or together to achieve the maximum possible benefits. FAST VP tracks the sub-LUN temperature at a 1GB granularity, and in turn, these data slices are automatically migrated to the appropriate tiers within a pool depending on temperature, while FAST Cache uses a memory bitmap to track the hit rates of data at 64KB granularity, this limits the size of FAST Cache that a given storage system can support. By combining both FAST VP and FAST Cache, users can scale their Flash tier to any size their application requires.
Some best practices for Oracle database deployment with FAST VP and FAST Cache:
FAST Cache Sizing
For a good sizing of FAST Cache, first you need to determine the hot data set of an application by some tools like Oracle AWR, Precise and ZettaPoint, Storage Performance Analysis etc., then sizing need to be done base on both capacity and performance and select which is bigger.
Sizing on capacity: Generally most of the OLTP database has 3-5% of active data compared to their capacity, so sizing FAST Cache as 5-10% of the total database size should handle more than 90% of the existing database.
Sizing on performance: Follow the performance guidelines for sizing the number of EFDs based on parity level and application read/write ratio.
Number of EFDs = (Reads of Front-end IOPS + write penalty x Writes of Front-end IOPS)/3500
Oracle Log Files with FAST Suite
The IO pattern on Oracle logs files, both online and archive, tend to be highly sequential in nature that rotating drives can handle very efficiently. EMC’s general recommendation is not to use either FAST Cache or FAST VP for Oracle archive files and online redo log files.
Separate Pools for Data and Log Files
EMC does not recommend placing Oracle data files and log files in the same pool for the reasons of:
Reliability: the transaction logs play a very pivotal role in Oracle Database recovery. In the event of data file corruption, the database administrator can go back to an older copy of the data file and apply the logs. Similarly if logs are lost, the Oracle Database can guarantee zero or minimal data loss if online redo logs are multiplexed to different sets of spindles. By putting data and logs into the same pool, the fundamental best practices of fault domains is ignored. Unless the user has some other data recovery plan like CDP, EMC does not recommend putting both data and logs in the same pool.
IO type and size: the IO profile of log files tends to be highly sequential. By mixing log files with data files, the sustained write bandwidth of a drive drops as the spindles begin to seek more often.
The Right Database Layout for a Highly Consolidated Environment
In the environment with multiple database applications, FAST VP can be used to create fewer multipurpose pools to guarantee SLAs rather than creating several small single-purpose storage containers, while still taking into consideration the criticality, fault domains, and IO characteristics of the data. For example, pool 1 with 15k SAS drives RAID 1/0 for all Redo Logs; pool 2 with 3 tiers of EFD, SAS, NL-SAS RAID 5 or 6 for all data files; pool 3 with NL-SAS only RAID 5 or 6 for all Archive Logs.