Oracle Database: Planning for New Storage

In this blog I cover topics which need to be considered when doing a new storage design for your Oracle Database. 

1. Review the current storage speed using the storage consoles which you have and find out the iops happening on the SSD Cluster + HDD Cluster, you can get iops and data transferred from the storages itself. From the current design, you must add the iops of SSD and HDD cluster and the data transfer as well

• design should include at least these much iops and probably a 20-30% more.
• design should be done considering the peak hours storage iops and the data transfer rates.

2. Design should/not enforce redundancy. 

• data is better handled by ASM redundancy, in case using ASM use ASM redundancy - Normal is preferred for DATA and FRA, High for REDO, CF and OCR.
• in case you are not using ASM then ask storage to include external parity and redundancy
• the effective storage capacity should be given as per the approach followed. 

3. A design having multiple disks performs better in oracle, as when you give the luns to oracle, it will stripe the data across the disks, thus maximizing performance. 

• design with many small disks can mean additional controllers and more management and more sockets to insert to.
• design with big disks again can reduce performance, so you should have a tradeoff with respect to cost and design.

4.  Latency which you plan should be as seen by Oracle and not from storage perspective

• from the AWR find out the current latency, min, max and average.
• In the AWR, you will have details of what you want or you can use my blog to find out latency of the events. 
• latency introduced by networking components should be considered
• networking should be such that it does not introduces a significant amount of latency
• latency planned should be the same at the maximum iops and maximum data transfer
• prefer to have redo, controlfile, ocr on fastest disks as these require less storage area.
• if you have a read intensive and dw application, you can have temp to on faster storage area. 

5. Any storage design should exclude any type of inline compression or storage optimization, unless the storage compression (at storage level) is certified by Oracle.

6. Migration to new storage depends on what type of design you use.

• when migrating to new storage always follow standby first approach
• when using ASM, use drop and add disks in the same operation
• these operations are resumable after restart of the cluster also
• when not using ASM, use methods such as duplicate and rolling switch of data files to minimize downtime.