Oracle Storage Layout and Performance Consideration with EMC Virtual Provisioning

Each thin pool contains devices of similar RAID protection, size and relative performance characteristics. A thin pool can also be shared by many thin devices with a total capacity smaller, equal, or larger than the actual physical space in the pool.  While it is possible to create up to 512 thin pools and therefore separate applications to pools, it is recommended to use only a small number of pools.  A single or small number of pools are easier to manage and monitor, and as a result each pool will have more devices, allowing better sharing of storage resources.  Therefore it is recommended to add pools only when additional storage tiers are needed, or when certain applications can’t share their storage.

From an Oracle layout planning perspective

• It is common for OLTP databases to separate log file placement from data (to allow Symmetrix business continuity solutions like offloading backups, or fast database restores).
• Temp files are not required for DR and are likely to be placed on separate devices.
• The oracle Flash/FAST Recovery Area and Archive logs can be placed on a slower storage tier than the main database files.

Therefore, outside the context of Virtual Provisioning, separation of log, data, temp, and archive/FRA was achieved by using different logical volumes (or metavolumes). In the context of Virtual Provisioning, this can be done by using thin devices in a similar way; however the thin pool can still be shared by the thin devices that require similar RAID protection and performance requirements.  The benefit of sharing the same pool is that Symmetrix business continuity and DR features work at the thin device level.  This allows for Oracle logs, for example, to benefit from the many devices (and therefore disk spindles) in the pool rather than be placed in another pool (or regular devices) with fewer disk spindles behind them.  When a separate storage tier is required (such as for FRA and/or archive logs) a different thin pool should be used.

In general, Virtual Provisioning provides a very good candidate for OLTP workloads by being natively striped across all the devices in the pool.  In order to keep the application performance balanced, when increase the pool size with additional devices, enough new devices should be added simultaneously so new data will be striped across them evenly.  Starting with the Enginuity 5874 Q4 2009 service release, the number of devices added simultaneously is less important, as long as a pool rebalance takes place afterward.