George Crump, of Storage Switzerland, published an interesting post recently titled Cost Effectively Solving Oracle Performance Problems. Crump explains the challenges of solving Oracle storage performance problems (including several Oracle instances) while keeping Oracle data in shared storage.
In his analysis, Crump details three solid-state storage solutions that address Oracle performance:
- Augmentation to existing mechanical storage via tiering or caching;
- Using SSD on Oracle’s application server itself to cache data;
- Using forklift upgrade solutions or database machines such as Oracle Exadata.
I agree with him on many points but disagree on others. First, here is what he says about Flash devices such as Kaminario K2:
Another option for optimizing the storage side of the performance problem is to use a flash-only device from one of the new start up storage vendors. The challenge is that typically these vendors have limited experience in delivering the types of storage services that Oracle administrators have become accustomed to.
At a minimum, new tools have to be learned and integrated into the workflow. They also use deduplication and compression to optimize a flash only investment, which can, in some cases, hinder overall system performance.
Finally, a new storage system means replacing the existing storage that may not yet be fully capitalized, as well as learning and integrating a new storage system.
From Crump’s posting
Here are my thoughts in response:
The challenge is that typically these vendors have limited experience in delivering the types of storage services that Oracle administrators have become accustomed to.
This is no longer true. Today, Kaminario K2 offers sophisticated SAN features important to Oracle administrators including lightening fast snapshots and non-disruptive operations.
They also use deduplication and compression to optimize a flash only investment, which can, in some cases, hinder overall system performance.
I agree that deduplication and compression can slow down Oracle performance and might not be a good solution for all Oracle workloads. However, K2 does not currently use deduplication and compression for database applications. Honestly, I keep asking myself why someone would use SAN compression when you can use database compression instead. I would let the RDBMS handle the compression. This, perhaps, is a topic for a future post.
Introducing any new product has a learning curve, but we are proud of the K2’s simple installation requirements (no tuning required). We have seen customers get up and running very quickly. For them, installation and integration has not been a significant issue at all.
Crump then talks about the option of keeping the existing storage and adding a flash read-only cache appliance. So, why am I against this?
The idea of caching is to quickly serve data that was served before. Most Oracle read performance problems are random read or single blocks. This is where mechanical disk storage is limited. If Oracle needs to read a block, that block needs to be in the cache appliance to improve performance. But will that block be in the cache? Only if that block is being used a lot (was served before). We call these hot-blocks. BUT, if these blocks are hot, they will already be in the Oracle internal cache and therefore Oracle will not read them. You’d end up double caching without a lot of improvements, unless the entire SAN data is placed in the caching appliance.
Some applications are dynamic in nature with real random access. You will not get much improvement from a caching solution compared with placing the entire database on a Flash array. We have seen this with Oracle Flash Cache vs. placing the entire tablespace on SSD.
I agree that caching will improve writes BUT not as much as placing an entire database on Kaminario K2. There is no doubt there.
Finally, if you really like your existing SAN and want to keep it, use a solution like Kaminario K2 mirrored to the existing SAN. Use ASM or OS mirroring to assure that writes go to both storages, but reads are served only from K2 (preferred read option). Then you will get both read and the write improvements. This solution will work for every Oracle application.
If you are having problems with your Oracle database performance, you should consider participating in our Oracle Database Performance Assessment. It is free and you will learn a lot about your Oracle database behavior from the experience.
Tags: application performance, database, Disk latency, Flash, I/O bottlenecks, K2, Kaminario, OLTP, Oracle, Oracle database, preferred read
